This privacy notice discloses the privacy practices for InFlow Machine Learning Inc. This privacy notice applies solely to information collected by this website. It will notify you of the following:
We are the sole owners of the information collected on this site. We only have access to/collect information that you voluntarily give us via email or other direct contact from you. We will not sell or rent this information to anyone.
We will use your information to respond to you, regarding the reason you contacted us. We will not share your information with any third party outside of our organization, other than as necessary to fulfil your request, e.g. to ship an order.
Unless you ask us not to, we may contact you via email in the future to tell you about specials, new products or services, or changes to this privacy policy.
You may opt out of any future contacts from us at any time. You can do the following at any time by contacting us via the email address or phone number given on our website:
We take precautions to protect your information. When you submit sensitive information via the website, your information is protected both online and offline.
Wherever we collect sensitive information (such as credit card data), that information is encrypted and transmitted to us in a secure way. You can verify this by looking for a lock icon in the address bar and looking for "https" at the beginning of the address of the Web page.
While we use encryption to protect sensitive information transmitted online, we also protect your information offline. Only employees who need the information to perform a specific job (for example, billing or customer service) are granted access to personally identifiable information. The computers/servers in which we store personally identifiable information are kept in a secure environment.
If you feel that we are not abiding by this privacy policy, you should contact us immediately via telephone at (647) 338-7105 or via email at support@inflowml.com
The value of data comes down to an organization’s ability to both interpret and convert it into an action where the outcome can be accurately predicted. In this post we discuss actionable insights and the importance of feedback loops and relevant information in making data driven decisions.
Insights derived from data provide numerous opportunities to drive growth in nearly all aspects of operations, but only if those insights are actionable. We spend a lot of time collecting, analyzing, and extrapolating information from our data and if we're not careful we can find that despite all our time and effort there is no clear path to leveraging it. This isn't a new realization. It is, indeed, the exact reason why the term Actionable Insights is so common today.
An actionable insight is information that provides a key path and expected result to a given action. In general, you have an actionable insight if you can format your proposed action in the following way: "Current Situation, which we know because of Insight. If we Action an Insight we should expect Result"
Let's take a medium sized municipality trying to improve their public transportation as an example. For months they have been receiving complaints from riders being passed by full buses during peak hours. With this information the municipality can extrapolate an Actionable Insight. Following the format mentioned above, we arrive at the following:
Riders are being passed by city buses. We know this because of the numerous complaints from riders if we add additional buses during peak hours we should expect the number of riders passed by city buses to decline (and so should the complaints).
This insight seems sound, has a clear action, outlines an expected result, all of which is based on primary data to boot. Adding more buses during peak hours is the next logical step.
Actioning the insight is incredibly important, but even more important is monitoring the results of that action. Doing so allows you to quickly test and adjust your insight In keeping with our example, the limited information available may not exactly determine the number of buses to add, but by diverting a few buses from their regular routes and monitoring the results it's possible to narrow in on the right number without utilizing too many resources.
It is incredibly common for an action to be made based on an insight and then left and forgotten only to take the same action down the road when the problem resurfaces. In this example, let’s say we monitor the number of complaints after additional buses are added to the route and find that there really is no change. Despite increasing the number of buses during peak hours, passengers continued to complain at the same rate. Although our insight made sense on the surface it was really based on a fundamental assumption that riders were being passed because buses were full.
In an attempt to solve this problem, each bus, along with 14 bus stops along the route, were equipped with people counters. With this simple set-up they were able to extract the following information:
They found that there were two specific stops along the route where it was common for riders to be left at the bus stop. This corresponded with the complaints received. Interestingly, internal bus counts showed that passing buses were at capacity only 58% of the time when people were left waiting. With a more granular problem identified – transit users left at bus stops while buses were not a full passenger capacity – it became clear that adding additional buses was not the right solution to this now redefined problem. Now that there is a more granular understanding of when and where to look, flow patterns for buses can be analyzed at the specific bus stops of interest. Moving along with our example, it's found that both stops have high entrance counts in comparison to exit counts. This means that significantly more people get on the bus at these stops than people get off the bus at these stops. Finally, it was found that buses often ‘bunched up’ during peak hours, with two buses within visual distance of one another. We'll call these bunches a convoy.
Once we had the right data we could identify (or at least get closer to) the true root cause of the issue, allowing the current situation to better and more adequately defined as well as addressed. It was discovered that the lead bus in the convoy was often at capacity and would only stop to drop people off and reload to passenger capacity, while the second bus in the convoy was very rarely at capacity. Counter intuitively, the average number of people left at the stop was higher when the first bus dropped people off and reloaded to capacity. As it also turned out, the second bus in the convoy would often skip right past that stop and then overtake the lead bus during these exchanges. After a quick validation with the bus drivers it became clear that when buses grouped into convoys they would leapfrog the bus before them whenever the lead bus stopped to pick up or drop off passengers.
With a little more data and significantly fewer assumptions it became clear that during peak hours buses often got backed up and started forming convoys with the lead bus often hitting passenger capacity prior to reaching the stops where most complaints originated from. Normally, lead buses would drive through and allow the next bus to pickup the waiting riders, and only stop when a passenger needed to get off at the stop. When the lead bus did stop for a disembarking passenger, the rear bus, assuming the lead bus could pick up all the riders at the stop would leapfrog. To illustrate this I've created a diagram showing the flow of passengers in each bus as they approach and depart from a stop.
This data informed the need to enforce a 'must stop' policy at these specific bus stops during peak hours. The rule: all buses must stop unless they are at full capacity. This would prevent buses that aren't at full capacity from leapfrogging, and passing over waiting riders. With this policy our new actionable insight now looks something like this:
Riders are being passed by city buses. We know this because of the utilization analytics conducted at each stop and on each bus. If we enforce a 'must stop'policy to prevent leapfrogging we should expect the number of riders passed by city buses to decline (and so should the complaints).
And our expected passenger flow diagram will look like this:
After actioning this new insight our monitoring showed that complaints fell, the number of times passengers were left at stops was reduced to 8%, and the average utilization of each bus rose.
It's not hard to fill in the blanks and come up with an actionable insight. But it is incredibly easy to bake in assumptions and fail to monitor the results of your action. To do so you always have to start with the desired result of your action and ensure the data you're using to identify a plan of action is relevant. Finally, more times than not you will need to test and adjust after each action taken, to hone in on a root cause and effective solution. Never be afraid to take action based on the information you have, even if it's limited, but always ensure that you monitor your actions to ensure you meet the desired effect.