Include Valuable Variables for Views

No its not that the data set isn't there, but that it is not organized in an easily usable manner. For example, we have the information to determine things like the open rate, amount requesting removal, or the successive bounce rates after opening, but it could be included as its own variable instead of relying upon the end user to do the digging/calculations themselves. More of a convenience thing.

This may be something already available in the Drupal 6 version and not available to the Drupal 7 version. I have not had the opportunity to use the previous version and would not be aware.

I would be more than happy to do that and have, in part, an executive level marketing background. I will put something together for you this evening and post it here.

In the sake of brevity and directness, I have opted not to submit a full-fledged marketing document to you. Instead I have provided below the core metrics which should be sought after first, why, and how to derive each. There are more metrics, but being that all projects on drupal.org are done a voluntary basis, I did not want to instill fog in the overall direction of the module with hundreds of minuscule statistics. Those variables listed below can be thought of as a “core” group of variables needed for all others that may be implemented at a later time. It is important to note that all these can be derived based on information you already store in the database and simply need a variable to makes the appropriate query when called upon. Further, these first few variables are not anything surprising, but should be completed prior to proceeding further. If you would like I am more than happy to list some more complex and less generally understood metrics.

I, in particular, intend to use the visualization api module to display this information to the end user in a graphical form for convenience. If you are not opposed to adding this dependency or another visual library (or making it optional), I would be more than happy to contribute the built / completed view as a starting point for those using the modules to modify. The views page we have begun building also includes an tabbed ajax header which brakes down the information into a variety of parts which have more detailed information: Total, Opened, Clicks, Bounced, Unsubscribed, Trends, and Comparisons to name a few, with each including specific detailed information like the top clicked links or recurring visits. With that said, the core variables needed:

Emails Sent: This is obviously a base variable needed to determine the majority of calculations. We have this information, although what is currently available to views is how many CURRENT subscribers there are. There needs to be a dedicated variable to the numbers of emails sent out in total.

Bounces: A bounce occurs when the address the email has been sent to is invalid. These messages are not successfully delivered. This is commonly used to derive the “bounce rate” or “delivery rate”, the rate at which emails were bounced back to the webserver and were not delivered (Bounce Rate = Bounces / Emails Sent). Bounce Rates can show us the level at which our emails are actually getting to their intended target. If the bounce rate is extremely high, it can show early on that the effectiveness of an email should be expected to be low. The formulas provided try to mitigate the effect bounce rates have on other metrics by using values not dependent on those emails which bounced.

Opens: This information is once again already tracked and just needs its own variable. The number of opens is important for obvious reasons. This can be used to derive the “open rate” which is a much more reliable measure of if the content of the email was effective in generating a desired action, be it visit x link or complete x. When deriving the open rate we are interested in seeing if those emails that were successfully delivered were actually opened, else there were probably simply deleted or ignored, which gives insight into a potential performance trend or ineffective subject lines / from addresses (Open Rate = Opens / Emails Sent – Bounces).

Unsubscribes: The number of contacts that have unsubscribed by use of the unsubscribe link. This is once again obviously important. It can be used to show performance trends and the effectiveness of an overall campaign. We, in particular, use this to compare different types of emails, and the subject matter, to see what sort of emails recipients respond positively to. That information can allow future emails to take on the form of successful email types or give insight which may justify discontinuing an email type in order to not saturate the recipient, causing them to ignore the emails they would positively respond to. The easy way to derive this would be to check the links table and see which are “remove” links. Obviously this variable is fairly easy to set and can be used to see how many contacts choose to unsubscribe. We once again will want to use only those emails that were successfully delivered. Since a contact will have to open the email in order to unsubscribe and an email must be successfully delivered to be opened, the formula can be shortened (Unsubscribe Rate = Unsubscribe / Opens). Traditionally, this is not how the unsubscribe rate is calculated; however, calculating it in the given manner gives us a more useful piece of information. Instead of how many of the total emails were unsubscribed to, we get to see how many of the people that were interested enough to open the email found the material useless enough to discontinue further emails. This could imply a glaring issue with the presentation of the material or the selection of targets.

Clicks: I want to mention what a fabulous job you have done in this area, we already track all clicks quite successfully. This can be expanded in several directions, one being, to determine the click-through rate, which tracks the number of times a link other than the unsubscribe link was clicked-through by the recipients. I believe you already store the number of times a link has been clicked as well in the links table. If not, it is simply a matter of querying the clicks table for the given link and seeing how many times it comes up, then eliminating duplicate clicks by the same user. This should only count 1 click on each link per email recipient as to limit skewed statistics from heavy outliers (Total Clicks (limit 1 per user) / Opens).

This would be extremely useful to allow users to select any link they have used in an email separately, such that the total number of clicks is contextually limited by the specific link. The benefit to this is that it gives the user an ability to tailor statistics to their use case and truly see what people are taking an interest in and what they are not. Also off this variable we will be able to provide a list of the top followed links, as well as, in what order they were clicked to give extremely valuable insight into the effectiveness of the layout of an email. This is probably the area that can become the most complex and can expand greatly to make Simplenews Statistics invaluable.

For Example: We in particular use Simplenews in conjunction with commerce. At times we may send out special offerings. By being able to isolate the number of clicks on the link to a special offering, it is possible to very easily determine the relative effect on the Simplenews email campaign on total revenue / sales. We would use this to find the revenue per email (RPE) by simply taking the total revenue from the given offering, originating from the emails, and divide it by the number of emails sent less the bounced emails (total revenue / (emails sent – bounced)). Further by understanding what links are clicked in what order and the click-through rate as a whole, future emails can be structured to encourage recipients to click on the priority links first and increase the effectiveness of the emails as a whole.

Performance Trends: This is not a core metric, but I wanted to provide one example of a metric which can be extended to at a later time that can be highly useful. We in essence can display performance trends of a given Newsletter through a simple formula to see if what we are doing is causing our emails to grow in popularity / readership or causing an urge to simply delete anything from the web server. An example with open rates can show us if people are tiring of our Newsletters by something like (Performance Trend = ((New Open Rate – Previous Open Rate) / Previous Open Rate) * 100). Over Several emails we will quickly be able to see if people find the content of our emails worthwhile and can see this effectiveness over several different Newsletter Categories. This is also sometimes referred to as the ROI of email marketing when using actually values like sales, ect.

As I mentioned this is not an exhaustive list of metrics as you requested. Instead I felt it may be easier to start with those core variables that must be provided to obtain the more complex metrics. I believe that with this variables, you will be able to see how basic variables can be used to derive the more complex metrics I am more than happy to provide in the view I would like to contribute (to be used in whatever way will progress the module). Feel free to let me know if there is a certain area you wish to discuss more or go into more detail or complex metrics with.

@weseze: I had a bit of free time today so I whipped up a new display. It is based in large part on the framework for the dashboard provided by the wonderful work of cvangysel at commerce_reporting. Credit should be given in part to him for the basic inspiration of the best practice for setting it all up and saving myself hours in the process.

With that said I currently have the menu path set to admin/statistics/reports/% for testing purposes. I have also provided the approach in a separate module should you decide this is not the path to take, thus the original statistics module remains unblemished. The argument in the form of the nid of the newsletter must be entered for the display to render things properly.

One major disclaimer is that there are several direct queries and whatnot that is not generally good drupal practice. These were used to simply speed up the display development and will have to be optimized along with other parts of the code should you decide this approach is the way to go. I am happy to help / contribute to this process.

Major Issue: Currently the table which tracks opens by the email recipients is not properly recording the nid column. All values are currently set to 0 in the table. This causes the open statistics to not give the correct values currently and will have to be fixed to approach those basic statistics.

All in all I have provided everything I outlined above and this gives us more of the basic platform for which to extend into more complex metrics. As I said this is just something for you to consider as it is your module. Just figured I would contribute a bit since I had some free time.