Building on my Masters Thesis on expanding a wine store from Bricks to Clicks, one critical component to establishing credibility and more importantly creating action (useful decisions through reviewing KPIs) from the online presence is to employ a robust usage monitoring program which can be accomplished with Google Analytics.
As discussed in the last blog posting, the data that populates the dashboards that decisions can be made from all comes from tracking of various attributes of user information captured by google analytics or other data capture mechanism.
In the case of the wine store strategy evolution, one of the main constraints is foot traffic and its limitations.
In a commodity business such as regular retail wine sales, location is very important. Especially in Manhattan, where there is a dense population of stores and the knowledge of wines is relatively low for the normal consumer. The result is that the consumer will go to the closest wine store, and not demand specific products, as a Merlot from California is relatively the same as a Merlot from New York.
The aforementioned scenario in mind, there is a specific following loyal to the store that may step out of their block code (micro-zip-code), for a special occasion, such as a class or tasting. The store is getting what seems to be good traffic from this type of allure.
The store does capture the email addresses, and we do have some basic preference data starting based on buying history, but a tool such as Google Analytics could really take this Analytical tracking and decision influencing to the next level.
The store doesn't know what the web site 'exit' or 'bounce' rates are.
The store doesn't know what products were viewed on the website nor what searches were run on the products.
The store does know (through another toolset) who we sent digital campaign emails, and if those were opened.
They also know if they actually clicked through on the offer, which would be of the 'organic referral' type, given we sent them the campaign in the first place.
It would also be good to be able to provide microtargetting to Chardonney lovers (ones who either bought Chardonney or said they like Chardonney) for Chablis offers.
As part of the recommendation from the Thesis, the suggestion is to set up a strategy for a comprehensive metrics plan, which will have both MTC (Measure to Control), as well as MTA (Measure to Analyze). This would allow for an enhancement both in business focus as well a customer focus.
One of the items mentioned above was to analyze the clickpaths and determine if the website can be enhanced to increase conversion or task completion.
Overall, there is a lot of digital work to be done in order to facilitate the migration more to Clicks than Bricks, and the analytical toolsets can assist with this strategy.
Sunday, February 23, 2014
Sunday, February 16, 2014
Measure what Matters - Dashboard Design and Usage
It was in the mid 2000's, and I was leading a team of engineers on a data warehouse on some PLCC (Private Label Credit Card) data. There were reports run, downtime, tickets issued, and ultimately, the customer (internal customer - business team, and external customer - the real client whose data it was) were complaining about the performance of the data warehouse.
This is a real life story on how design of the dashboard, and how one manages those who review the dashboards actually works in the real world.
The following are my lessons learned on how to effectively manage a dashboard of the right metrics at the right time.
1) Have a dashboard that is aligned to be meaningful to whoever is looking at it.
2) There may be different stakeholders reviewing the dashboard, thus may need a permissioned, and personalized dashboard for the different stakeholders. Case is point is that a practitioner may want to have the internal metrics on one part of the dashboard, while presenting the external metrics on the other part of the dashboard.
3) One often has a baseline on what the stakeholders want and what they are looking at to represent what they want, and there may need to be changes to the data presented to ensure that they stakeholders are reviewing what is important to their business. Often times, the tech teams are so hung up on what they think is important, that they only have half of the story is being told, and there is extra or dependent information that must be in context to tell the whole story.
4) After interviewing the business team, and the business-tech translation team, then the actual needs of the report become unveiled, and the tech team can begin to make provisions to create that report on a reliable basis for leadership to review.
5) Many times, the reports do not add value, and thus go unreviewed, and sorry to say, but even though an entire team may spend the entire week generating that report, at times, it is only reviewed for a minute or not at all by the business executives.
6) My view is the aesthetics of the report are not as valuable as the ability to tell a message with the data.
Telling the message with the data actually takes a lot of hard work understanding the goals of the executive, and the variety of political context that they executive may be under.
7) Designing and populating a dashboard to drive decisions is key and the aforementioned items help to contextualize the importance of the various components of the dashboards.
8) There are various tools that do a good job of fetching the data and summarizing it into the valuable formats that the data provides so that the executives are able to make better decisions after reviewing the data.
I trust that this blog has provided a bit of insight into using dashboard to measure what matters and ensuring that the dashboards have the right data and format to support the right messages that ultimately lead to the most effective decisions being made with the data on those dashboards.
This is a real life story on how design of the dashboard, and how one manages those who review the dashboards actually works in the real world.
The following are my lessons learned on how to effectively manage a dashboard of the right metrics at the right time.
1) Have a dashboard that is aligned to be meaningful to whoever is looking at it.
2) There may be different stakeholders reviewing the dashboard, thus may need a permissioned, and personalized dashboard for the different stakeholders. Case is point is that a practitioner may want to have the internal metrics on one part of the dashboard, while presenting the external metrics on the other part of the dashboard.
3) One often has a baseline on what the stakeholders want and what they are looking at to represent what they want, and there may need to be changes to the data presented to ensure that they stakeholders are reviewing what is important to their business. Often times, the tech teams are so hung up on what they think is important, that they only have half of the story is being told, and there is extra or dependent information that must be in context to tell the whole story.
4) After interviewing the business team, and the business-tech translation team, then the actual needs of the report become unveiled, and the tech team can begin to make provisions to create that report on a reliable basis for leadership to review.
5) Many times, the reports do not add value, and thus go unreviewed, and sorry to say, but even though an entire team may spend the entire week generating that report, at times, it is only reviewed for a minute or not at all by the business executives.
6) My view is the aesthetics of the report are not as valuable as the ability to tell a message with the data.
Telling the message with the data actually takes a lot of hard work understanding the goals of the executive, and the variety of political context that they executive may be under.
7) Designing and populating a dashboard to drive decisions is key and the aforementioned items help to contextualize the importance of the various components of the dashboards.
8) There are various tools that do a good job of fetching the data and summarizing it into the valuable formats that the data provides so that the executives are able to make better decisions after reviewing the data.
I trust that this blog has provided a bit of insight into using dashboard to measure what matters and ensuring that the dashboards have the right data and format to support the right messages that ultimately lead to the most effective decisions being made with the data on those dashboards.
Sunday, February 9, 2014
Just the facts... for the DBA - oh and quality too...
Working in the credit card space for nearly 20 years, and focused on business performance supporting by IT systems and processes, I can say that a well designed DB is paramount for system performance, leading to good reporting, good decisions, and a successful business.
One aspect of the SDLC that occurs more than any CIO would like to admit, is that the due dates for the system (capability) readiness are set in stone without a good vetting of the entire process to actually achieve those business outcomes with the foundational aspects of the systems and processes.
The net effect of setting due dates for launching capabilities is that certain critical but not well understood processes get squeezed in the SDLC, and then the executives scratch their heads on why the overall ROI is not being generated from the system capability.
The two phases that I often see cut the most due to lack of understanding are design and change management.
We will focus on the "facts" of the DB design since we are studying facts and dimensional modeling in this section of the class. Having the right expertise as well as sufficient time to properly design the DB is absolutely critical to the overall system capability performance.
Imagine building a house, and not spending much time on how the hallway connects to the bathroom and then potentially having 2 or 3 floors, but a missing staircase inside, but one outside? The net result would be that one would have to go outside of the house, then climb up the stairs and up to the second floor. This is a similar type of thing that the queries will have to do if they have to make joins that are not efficient and end up with a performance cost.
The design of the facts and dimensions is the critical aspect of this and a fundamental tenet to the overall system performance. Paying close attention to the attributes that one includes in the various tables is key as it can also serve as an audit to the requirements analysis phase that is performed as well.
If one thinks about the end goal of the system and realizes that they will need to have some historical data on the addresses, and chooses Type 1, then that is the wrong design. This can be caught during the design phase.
Also, If there are a number of Yes/No attributes, then one can utilize the junk dimension design to remove some of the attributes that will make the fact table explode in volume and have a simpler more performance oriented design by putting those attributes in a related dimension table.
Another aspect that can improve performance and maintainability is whether to employ a snowflake design with the normalization of the tables.
All of these design decisions effect the queries that will select the data and return it to a report for executives to see or for other program applications to utilize for various system functions.
Another aspect of good DB design and system cleanliness is data quality, as well as master data management. There are a number of great profiling tools in the market today, and many can be automated to perform cleansing, deduping, and other quality checks on the data to ensure efficiency and effectiveness in the system.
In summary a good design through spending adequate time on design of facts, dimensions, and the right schema, as well as having good data quality processes and tools in the system, will enable the business performance metrics to be met more naturally in today's environment.
One aspect of the SDLC that occurs more than any CIO would like to admit, is that the due dates for the system (capability) readiness are set in stone without a good vetting of the entire process to actually achieve those business outcomes with the foundational aspects of the systems and processes.
The net effect of setting due dates for launching capabilities is that certain critical but not well understood processes get squeezed in the SDLC, and then the executives scratch their heads on why the overall ROI is not being generated from the system capability.
The two phases that I often see cut the most due to lack of understanding are design and change management.
We will focus on the "facts" of the DB design since we are studying facts and dimensional modeling in this section of the class. Having the right expertise as well as sufficient time to properly design the DB is absolutely critical to the overall system capability performance.
Imagine building a house, and not spending much time on how the hallway connects to the bathroom and then potentially having 2 or 3 floors, but a missing staircase inside, but one outside? The net result would be that one would have to go outside of the house, then climb up the stairs and up to the second floor. This is a similar type of thing that the queries will have to do if they have to make joins that are not efficient and end up with a performance cost.
The design of the facts and dimensions is the critical aspect of this and a fundamental tenet to the overall system performance. Paying close attention to the attributes that one includes in the various tables is key as it can also serve as an audit to the requirements analysis phase that is performed as well.
If one thinks about the end goal of the system and realizes that they will need to have some historical data on the addresses, and chooses Type 1, then that is the wrong design. This can be caught during the design phase.
Also, If there are a number of Yes/No attributes, then one can utilize the junk dimension design to remove some of the attributes that will make the fact table explode in volume and have a simpler more performance oriented design by putting those attributes in a related dimension table.
Another aspect that can improve performance and maintainability is whether to employ a snowflake design with the normalization of the tables.
All of these design decisions effect the queries that will select the data and return it to a report for executives to see or for other program applications to utilize for various system functions.
Another aspect of good DB design and system cleanliness is data quality, as well as master data management. There are a number of great profiling tools in the market today, and many can be automated to perform cleansing, deduping, and other quality checks on the data to ensure efficiency and effectiveness in the system.
In summary a good design through spending adequate time on design of facts, dimensions, and the right schema, as well as having good data quality processes and tools in the system, will enable the business performance metrics to be met more naturally in today's environment.
BI and executive use of Balanced Scorecards
As I work with clients on a daily basis from mid level executives to C-suite execs, the level of detail of information shared with them is absolutely critical to facilitating good decisions,and ensuring productive use of time.
There is a deluge of data out there, and the ability to coalesce this data into a meaningful set of summary pages for maximum understanding and decision making is a skill that will propel many consultants and aspiring executives in their career.
Many business liaison team members (ones that translate from tech to business speak ;)) as well as tech team members often obsess in the systems and data, and lose site of the goal of the data and what it is being used for.
With our teams, I try always to begin with the business perspective, which is ok, in this particular promotion, we have the following business goals, which is lift, and retention, so how can we achieve that.
I need the team to pull from SAS a clean set of target market customer names in a particular geo so that we can share our creative ideas with them. We get together at the beginning of the week and discuss 10 promotions for the week, and then perform the data pulls, manage the systems, execute the promotional campaigns, and then measure the results, all to inform the next set of promotions the next week. I am simplifying dramatically, but just for the example.
Then, Tuesday, the database maintenance wasn't performed properly overnight, so our SAS jobs for the day didn't complete on time, which creates lag time in the team productivity, as well as hampers our ability to reach our goal of the precision of the target market definitions.
This scenario above begins to paint the picture for what the SDLC for the marketing promotional lifecycle is as well as provide the background context for the balanced scorecard example I will describe.
Every week on Wednesday there is a meeting to review the prior week's sales promotions effectiveness, and this goes along with the above context on a rolling cycle, so that we can inform the next week's targeting with the campaign performance from the prior week. This is the primary use of the marketing effectiveness balanced scorecard. (Ideally, the CMO, and CIO would attend the weekly steering committee review)
The attributes (fictional, but directionally real are):
- Financials invested in campaign promotions
- System metrics (server performance, downtime, jobs abended, disk space, etc.)
- # of campaigns promotions in the market
- Performance of said campaign promotions
- Channel diagnostic (web, social, direct mail), etc.
- Financial ROI on the promotions.
The key aspect of this balanced scorecard is to provide the right level of data for the executives to understand the impact of their decisions and to make the right ones.
For example, if the CMO is under pressure for sales results, and wants to triple the volume of campaign promotions for the week, but it is a week that there is a server maintenance window within it, many times this information is like ships passing in the night, but they actually, in this case, crash due to the fact that the system actually can not operate at that level during a maintenance window.
This type of meeting driven by a balanced scorecard will enable communication with the right level of informational facts at the fingertips of the executives to drive good decisions.
One may think that the above is a far fetched example, but I must say that it happens more than the executives would care to admit, and the end result is a drag on business performance.
There is a deluge of data out there, and the ability to coalesce this data into a meaningful set of summary pages for maximum understanding and decision making is a skill that will propel many consultants and aspiring executives in their career.
Many business liaison team members (ones that translate from tech to business speak ;)) as well as tech team members often obsess in the systems and data, and lose site of the goal of the data and what it is being used for.
With our teams, I try always to begin with the business perspective, which is ok, in this particular promotion, we have the following business goals, which is lift, and retention, so how can we achieve that.
I need the team to pull from SAS a clean set of target market customer names in a particular geo so that we can share our creative ideas with them. We get together at the beginning of the week and discuss 10 promotions for the week, and then perform the data pulls, manage the systems, execute the promotional campaigns, and then measure the results, all to inform the next set of promotions the next week. I am simplifying dramatically, but just for the example.
Then, Tuesday, the database maintenance wasn't performed properly overnight, so our SAS jobs for the day didn't complete on time, which creates lag time in the team productivity, as well as hampers our ability to reach our goal of the precision of the target market definitions.
This scenario above begins to paint the picture for what the SDLC for the marketing promotional lifecycle is as well as provide the background context for the balanced scorecard example I will describe.
Every week on Wednesday there is a meeting to review the prior week's sales promotions effectiveness, and this goes along with the above context on a rolling cycle, so that we can inform the next week's targeting with the campaign performance from the prior week. This is the primary use of the marketing effectiveness balanced scorecard. (Ideally, the CMO, and CIO would attend the weekly steering committee review)
The attributes (fictional, but directionally real are):
- Financials invested in campaign promotions
- System metrics (server performance, downtime, jobs abended, disk space, etc.)
- # of campaigns promotions in the market
- Performance of said campaign promotions
- Channel diagnostic (web, social, direct mail), etc.
- Financial ROI on the promotions.
The key aspect of this balanced scorecard is to provide the right level of data for the executives to understand the impact of their decisions and to make the right ones.
For example, if the CMO is under pressure for sales results, and wants to triple the volume of campaign promotions for the week, but it is a week that there is a server maintenance window within it, many times this information is like ships passing in the night, but they actually, in this case, crash due to the fact that the system actually can not operate at that level during a maintenance window.
This type of meeting driven by a balanced scorecard will enable communication with the right level of informational facts at the fingertips of the executives to drive good decisions.
One may think that the above is a far fetched example, but I must say that it happens more than the executives would care to admit, and the end result is a drag on business performance.
Subscribe to:
Posts (Atom)