lunexa.com

Web Analytics - How Big is Your Blind Spot?

2013-04-10T15:57:55Z

Web Analytics data tells you most everything you need to know about your customers’ online behavior but there is a lot it can’t tell you – like who the customers are who are visiting your site, and how they may be interacting with your brand through non-digital channels.

From a marketer’s perspective, this missing data is vital data, since every marketer’s goal is to close the loop between a consumer’s digital behavior and their offline spending.

The large blind spot in the field of web analytics can be overcome. The solution starts with taking the rich website analytics data from tools like Adobe Omniture SiteCatalyst® and integrating with traditional customer and transactional systems. Fortunately, it’s a process that can be made a lot simpler than it sounds.

Problems will persist as long as companies look at website data in a silo. Implementing a web analytics solution is a job only half done. The next phase which is equally important is integrating the Omniture data in the cloud with a company data warehouse in order to reconcile all the fragmented analytics views throughout the company into a single view of the customer.

Once this is done —and the aggregate, anonymous 30,000-foot insights of the web analytics channel can be combined with actual known customer IDs — stunning new marketing possibilities can be opened up.

Are you missing the boat with a web analytics (silo view), rather than customer analytics (integrated view)?

Here are some examples of insights our clients have been able to achieve by integrating their Omniture data. See how you stack up:

Retail. A merchant knows when a consumer who bought a sweater at the brick-and-mortar store has also visited the website three times looking for woolen scarves, gloves and hats. The retailer can formulate a marketing campaign with a series of follow ups to re-target the consumer with offers based on this information. Separately, the merchant can track an abandoned a shopping cart to determine whether a purchase may have been completed in a store, or if there is another reason why a purchase was attempted multiple times but wasn’t ultimately finished (perhaps the person may have encountered trouble with the website, needing specific follow up action).

Financial Services. A retail bank is able to compare the customer’s financial products with his browsing history during recent visits to the website. The bank can then put together promotions tailored to the individual’s interests and needs. Customer service at the bank also has this information, so when the customer calls into the call center, the agents know which products he browsed. They can suggest products over the phone or they can notice he had problems accessing certain areas of the website and provide support.

Digital Content & Media. A leading media and entertainment company merges its web analytics and its ad server data in order to target ads to individuals based on their specific interests and browsing history. Say while browsing sports scores on a sports website a consumer clicks on a sports-related product ad. Later, while he shops for gifts for his children on a children’s site, he may see ads targeted toward sports, because marketers know his individual browsing history.

Look for our weekly emails on how to expand your web analytics 360 degrees

Upcoming emails will offer detailed client case studies, a solution brief and tips for integrating web analytics out of the box. Visit http://www.lunexa.com/solutions for more information anytime, or contact us at info@lunexa.com. FB/Twitter/Linked In.

Dashboard Visualization Best Practices

2012-11-07T03:34:37Z

Because 70% of our sense receptors are visual, one of the most important aspects of dashboard design is to have the right type of visualization. The data that the dashboard displays should be shown in a way that makes the most sense, and let the user understand the data in the best possible way. While color, images and fancy graphs might make the dashboard look more appealing, it is important not to let these features take away from the most important part of the dashboard – the data.

Here are some basic visualization best practices that we generally follow at Lunexa. While these are not strict rules, we’ve found these to be helpful guidelines when creating visualizations that are most effective.

Pay Attention to Layout
The placement of the most critical information in a dashboard is important, as the user will naturally focus his/her attention more heavily in certain areas of the dashboard. The center and top-left section of the dashboard is where the most critical information should be placed. The least critical information should be placed in the low-right corner.

Graphs
Avoid pie charts. While pie charts are common, they might not be the best visualization to use. It is difficult to interpret the relative sizes of the slices of a pie chart. A bar graph is a better alternative in this case.

Avoid 3D graphs. Usually, not all of the data is visible in a 3D graph. Furthermore, it is difficult to do comparisons. A better alternative is to have multiple column graphs one on top of the other, to facilitate more effective comparisons and analysis of the data.

Avoid unnecessary color. In the example below, having a different color for each column in the column graph is unnecessary and even distracts the user from the data. Having just one color for all columns actually works better in this case.

Avoid gauges. People seem to think that because our car and planes contain dashboards, we must have them in business intelligence dashboards too. Actually, they don’t provide many added benefits. Gauges show very little information and take up a lot of space. A bullet graph is much more effective in conveying the same information, but in a much smaller space. Real estate is precious on a dashboard and the space saved by using a bullet graph instead could be used for other information.

Auditing Techniques from Within Ab Initio Graphs

2012-11-14T17:44:33Z

Some clients may propose using auditing techniques within the Ab Initio graphs themselves, rather than using scripts to check logs, or using SQL to check for which data was loaded. This approach can be useful for handling Ab Initio graphs when trying to specifically identify the issue records, but the technique can also be used to determine reject counts, lost records on joins, and duplication counts. Of course, record counts can still be identified by parsing through Ab Initio graph logs and scrubbing through dropped records landed to reject files.

The following table summarizes some of the pluses and minuses to using auditing techniques within Ab Initio.

+ Build job-specific auditing into the actual job and reduce the amount of additional audit jobs to perform.

+ Perform auditing at the file-level.

+ Quickly identify the data issues specific to each record by performing the reject identification, record reformatting, and attachment emails in one process.

- Some possible usage of End Scripts, which clients may not want to use.

- Not generic. Understanding of the auditing process per job will be specific per job.

Phasing:
The use of Phases within Ab Initio allows us to run the ETL logic that is required, but to also perform an additional check afterwards. By setting the auditing checks in an additional phase, we can still perform the ETL, but then immediately check on the different aspects of the job run without having to call up another graph or script. Failure on the job during the auditing phase can also be acceptable in the case of the job failure acting as more of a hard warning since the ETL will have already completed.

Forcing Failures via Reformat:
Ab Initio graphs can be forced to fail out via the Reformat. The failure can be decided through a specific record count, an improper value within a field, or any form of data that can be checked with basic IF statement checks. Forcing a failure can create a hard warning that is more effective in drawing attention to an issue.

Dropping issue records into Excel for Warning Emails:
Contents from any records can be reformatted and loaded into an Excel spreadsheet that can then be emailed out as an attachment. The contents of the spreadsheet can be customized and include any specific values from issue records identified. This is particularly useful for calling out issue records by their unique identifiers so that a developer can go back to the source data and quickly identify the issue records that were rejected. A simple spreadsheet can also provide a quick overview as to how many records had issues, what type of records they are, what fields look incorrect, etc.

Facing The Reality of Data Governance and Quality

2012-11-07T02:13:07Z

Virtually all companies experience data quality challenges, some more than others. Chances are, the bigger your company, the bigger your problems. Nowadays, corporate data comes from many sources, such as company website traffic, social media, financial systems, marketing/sales systems and company specific operations systems. Incoming data from all of these sources can be riddled with inconsistencies, blanks and plenty of “fat-fingered” accidental typos. In spite of all this, integrating all these sources of data for a single version of truth is invaluable for discovering strengths, weaknesses, and key performance indicators of your company.

Still, standardization of incoming data has been slow to take hold. Data quality issues continue to arise and spread. Companies that are tackling data quality on a one off/one time basis are often merely acting tactically, and in these instances, usually they are not actually succeeding at solving their data quality problems in the long term. As a result of their struggles, many corporate leaders are now realizing the importance of data quality as a strategic initiative. To succeed and sustain a data quality initiative one must truly embrace data governance for the long term to support that initiative.

Data governance is one of those things that most people hear about and run the other way – and rightfully so. It has the reputation of being a slow moving, boring, and a failing endeavor. However, next to a company’s employees, its data resources are among its most prized assets. Data is an extremely valuable and largely untapped resource that has gained serious momentum over the past decade, with an increasing number of business intelligence technologies available to help harness its value. The reality is that, in order to fully maximize the data asset and capitalize on all that it has to offer, companies must face the quality challenge head on.

Here’s the good news: Data governance is really just a means to orchestrate the people, efforts, processes, and technologies needed to optimize data quality. Interestingly enough, data governance has been embraced by the Sarbanes Oxley Act (SOX) to manage risk and compliance as it relates to data – an important step.

Of the many organizations out there, very few have successfully completed the #1 key component of data governance: The data governance charter. Either the charter exists in various islands across the enterprise, or the charter is written in such a way that it’s missing the basics that enable data governance to be sustained over the long term.

Think of the charter as your project requirements document in the IT world. Without a good understanding of the project requirements, projects usually fail. This is a known fact. The same happens with data governance that has a poorly written or non-existent charter.

Provided below for your convenience is a no-nonsense outline of key components that should be addressed in your data governance charter. Keep in mind, a charter will take on a life of its own from one company to another, but it should include these basic sections:

Business Problem Statement
Program / Project Goals
Program / Project Expected Results
Your Data Governance Definition
Data Governance Responsibilities & Objectives
Data Governance Differentiator
Assumptions Driving the Need for Data Governance
Planned Data Governance Accomplishments
Data Governance Value
Data Governance Strategic Initiatives
Data Governance Start Plan
Data Governance Stewards
Data Governance Sponsor
Data Governance Coordinator
Data Governance RACI (responsible, accountable, consult, inform) Matrix

Best Practices for Ab Initio

2012-11-07T02:13:58Z

The importance of following these best practices for Ab Initio might not be evident at first. You can create new graphs without following these methods and everything will seem smooth – for a time. Yet, after a while, your processing will become more delayed and your code merges will become more difficult. You can avoid many challenges down the road by taking a few of the following initial precautions.

Ab Initio Best Practices
1. Limit your usage of the start/end scripts. You are focusing on performing specific commands via Korn Shell and not using the more visible Ab Initio components to perform these tasks. There is a reason why Ab Initio does not easily display start/end scripts and it is to discourage the usage of this feature.

2. Perform your transformation processing in the graph. Sorting, Joining, Aggregation, etc. should be processed ahead of time for SQL querying end users. You'll also benefit from Ab Initio's parallelism when performing these functions. Using Ab Initio for just basic record transformation is like buying a Porsche and driving it 10 mph all the time.

3. Perform multiple sets of transformations in one graph with phases. Don't just create one graph per each individual set of transformations. You will lose processing time to the startup/end phases of each graph and just over-complicate your set of jobs by having too many "mini" graphs. However, don't overuse in-memory transformations. Be smart about your phasing and land-to-disk when necessary.

4. Use parameter-passing as much as possible, especially within subgraphs if possible. Logic can be baked into these parameters and it is preferable to avoid hardcoding, especially within subgraphs which developers do not always pay attention to.

5. Simplify your component usage. Some components have multiple functions, such as a Reformat being able to provide Transformation, Filtering, and Port Re-definition all-in-one rather than using a Filter, Reformat, Replicate, and additional Reformat/Filter components.

6. Keep your graphs clean. Create subgraphs when necessary, name your components properly, use the legend text features for labeling, and arrange your components in a way to convey what your data is doing. Ab Initio is visual for a reason. A picture is worth a thousand words, so a well arranged and labeled graph is word a thousand lines of code. Visual representation of your ETL logic is intended to avoid spaghetti code. Do not just mix around components into another tangle of mess.

Approaches to Collaborative Dashboard Design

2012-01-13T07:03:07Z

In many situations when we are engaged in implementing a BI project, the state of requirements is far from finalized – this is particularly true when implementing dashboards. Users often have a sense for what information they would like to have visibility on, but they may not have sufficient familiarity with the underlying technologies to effectively articulate the nuances of information presentation, interaction and navigation which is core to a successful dashboard. If these details are not fleshed out prior to the development phase, the project may run the risk of multiple development cycles to address end-user feedback (or simply fall short of their expectations).

Successful dashboard projects require a collaborative and iterative design approach, with a close partnership between the technology and business teams. Our successful projects working with several Fortune 50 clients have ensured this collaboration through the following methods:

Focus working sessions and requirements finalization around types of end users
- Keep working sessions focused by conducting multiple sessions with groups of end users/stakeholders with common information needs
- Consolidate the superset of requirements and perspectives on how different user groups would like to interact with the metrics and supporting data elements
- Educate end users on any common / divergent requirements
Clearly identify the specific business questions that each user group needs to answer
- Understand the underlying business processes and how information fits into the decision making components of those processes
- Identify the follow-up questions that may arise as information is consumed
- Be wary of trying to serve too many constituents with a single dashboard. Users with differing information needs are best served with dashboards that are tailored to their needs rather than wading through generic
Conduct conference room pilots with the business partners
- Doing development real-time with business partners streamlines requirements clarification, educates the end users on the technology and promotes goodwill
- Tailor report presentation to facilitate information comprehension
- Ensure that the dashboard provides the contextual information required to interpret metrics
- Provide appropriate information and navigation required to support analytic workflow
Enable actionable reporting
- Organize and present metrics around business processes
- Identify systems and processes where dashboards can be embedded
Enable consistency and transparency
- Provide consistent metric calculations across reporting environments and support drilling to lower-level detail to support business needs
Prioritize releases to reflect end user needs and data availability
- Strive for incremental releases where possible to show progress and drive end-user engagement