Philosophy of Analytics, Lesson Five: How (Form and Material Causes)

Introduction

In lesson one I discussed the importance of keeping in mind the purpose of analytics when you are starting and designing and running an analytics project (the why of analytics).   In lesson two, I discussed the importance of understanding the who behind analytics: who is doing it and who is it for.  In lesson three, I answered the when question: when should one use analytics? In lesson four, I addressed the where question: where is analytics important?

In this final lesson, we turn to the how question: how do you do analytics?  Since this can be answered in many ways, I am framing this question by looking at the two remaining causes from Aristotle: the material and formal causes.  That is, what constitutes the material of analytics? What constitutes the form of analytics?  These are closely related and so it makes sense to address them together.

By form, I mean the forms that "analytics" can take, independent of any specific implementation.  By material, I mean the specific implementation of a form.  For example, data can be presented in the form of a table.  However, the specific implementation can be in a database table or in a spreadsheet or an online table.  We can be even more specific by mentioning the specific software: Excel, SQL Server, MySQL, Oracle, Google Sheets...

How: Form and Material Causes

Here is an overview of the various forms and materials available for doing analytics.  This is a very incomplete list, and contains only what I know about and am most familiar with.  I am on this journey of discovery with you, and I am sure many other additions could be made.  Consider this a starting point.  I will discuss the step in the analytics process, the forms available in that step, and some examples of specific materials available for those forms.

Step 1: Database pipeline/database management

First, you need to get data, and you need to get it in a regular, stable, predictable, and automated way (ideally).  And you need to be able to store it and clean it.

• Database server:
• Typically, one pulls data from various sources into a database on a server where it can be cleaned up, transformed, and queried easily.  One can automate this process scheduling jobs to pull the data regularly, and monitor the process using logs and alerts.
• Examples:
• SQL Server: Microsoft's relational SQL database solution.
• Access: Microsoft's Office relational database for small applications
• Oracle: has relational SQL and also NoSQL solutions
• MySQL: an opensource relational SQL database solution
• MongoDB: NoSQL database for big data applications
• Cloudera: Hadoop big data solution
• Spreadsheets/flat files:
• One can pull data into spreadsheets and flat files.  This is often necessary when connecting to online sources of data.  These are easy to clean and change.
• Examples:
• Excel: Excel is widely used to pull and store data.
• Google Sheets
• PowerQuery: an add-in to Excel which can make pulling data from various sources a lot quicker and easier.
• CSV: a common file format, comma separated value (CSV) files make it is easy to share one-time data requests.

Step 2: Data warehouse/data integration/metric definition

Now that you have data stored, you need to integrate it together in useful ways, relating one set of data to another set of data.  A data warehouse is a useful place to define relationships and create metrics so that your individual data sets can be treated and used as an interrelated single data set.

• Data Warehouse
• Example:
• SQL Server Analysis Services: Microsoft's data warehouse solution.  Use MDX to build cubes that can be queried in reporting.  Define metrics, KPIs, and pre-aggregate data for faster reporting refreshes.
• Other
• Example:
• PowerPivot: an Excel add on to bring a data warehouse inside an Excel file.  Use it to pull and refresh data, relate tables, and define metrics.

Step 3: Basic reporting from data warehouse/databases

Now that your data is integrated, you can use the data for reporting.  Connect to your data warehouse or databases and start reporting the data contained in tables to your users.  Reports are intended to show detailed data and status; they are generally static  and can show actuals of metrics vs. target values for those metrics with granular detail for many important fields.  What were sales like in every branch over the past three months?  Which users were using your software this past year?  You can display this information in a tabular format for your stakeholders to digest and assess the status of various metrics at a detailed level.

• Reporting Service: some software has the capability of automating pre-defined reports that can be emailed on a scheduled basis.  These pull data automatically, and display the resulting table for users to see.
• Example:
• SQL Server Reporting Services: Microsoft's reporting service
• Spreadsheet: most reports I have seen come as spreadsheets, usually with some minor charts to show trends over time.  These are generally manually refreshed on a regular basis (pull the data, copy/paste into the file) and then emailed to users on a distribution list or posted in a shared location.
• Example:
• Excel
• Google Sheets

Step 4: Dashboarding

Once you have basic reporting, make it easy for your users to interact with the data and to gain insight into that data.  Help them acquire answers to their questions: why did sales go up this past month?  In what country did sales go up the most?  Is there a particular client most responsible for the increase in sales?

The point of a dashboard is usually not to merely report detailed status but to provide insight into how a wide variety of factors may influence a metric, and to show how key metrics are changing over time at a broad level.  This can be done in several ways. 

First, a dashboard can (although not always) allow users to slice and dice across the interrelated data set.  Users can isolate different facets of the data, try different combinations of filters, etc. all to understand how different fields are related.   If the dashboard does not allow users to filter or slice, then in one sense it is a dashboard in that it can visually display key metrics, but it will not help users understand what is really going on in driving those metrics or what key factors are important.  Whether this matters comes down to the point of the dashboard: is it meant to be displayed on a TV monitor and updated regularly for status, or is it meant to be leveraged by users through slicing to gain insight?  Each kind of dashboard has its place, and you need to decide what purpose your dashboard will serve and design accordingly.

Second, the data is NOT static.  Often, it is desirable to have more regular refreshes of the data (hourly, daily) so that progress can be tracked more closely and trends can be spotted more quickly.   A dashboard is meant to keep track of ongoing metrics that are key for an organization and which can lead to action.  They are meant to provide an overview of what is going on at this point in time and as time goes on.  If the dashboard only reports static data in a visual way, then it should probably be called a visual report, not a dashboard.

Third, metrics are displayed graphically instead of tabularly, and are placed together in ways that complement each other.  For example, one might have a dashboard with sales trends month over month, transaction counts month over month, sales totals by country on a map, and transaction counts by country on map.  These are all related, and one can quickly gather insight into the relationship between sales, transaction counts, and location by scanning the dashboard.  If data is being shown tabularly, then it is definitely not a dashboard and is more like a query tool (with slicing) or a regularly updating report.

Check out this for more thoughts on the difference between a dashboard and a report.  In short, reports are detailed and tabular and focus on a specific set of data in general.  Dashboards are visual, broad, and focus on a group of key metrics that are meant to be tracked over time and are actionable.  In the end, think about what purpose your report/dashboard will serve before creating it.  It matters less whether it is a pure dashboard or pure report.  What is important is that it serves the needs of your organization in the most effective way according to its intended purpose.

• Dashboarding: these are programs specifically designed for doing dashboarding.  One can ingest data, relate the data, define metrics and KPIs, and visualize the data in dynamic charts that a user can click and slice through to gain insight.
• Example:
• PowerBI: Microsoft's latest stand alone solution for BI dashboarding.  Takes the PowerPivot, Power Query, and Power View add ins from Excel and places them in a single application.
• Tableau
• QlikView
• Spreadsheet: you can use spreadsheets to create a dashboard.  When connected to a server, regularly refreshed, and visualized, they can be a simple and effective means of dashboarding.
• Example:
• Excel
• Google Sheets

Step 5: Predictive/advanced analytics, statistical analysis, machine learning

Now that you have good data to work with an idea of what is important to look at (based on your dashboards), you can start to do deeper analysis and focus on the why of the past to give guidance about how to anticipate, influence, and take advantage of the future.  Examples of the sorts of analysis you do can include:

• Regression: Use statistical software to create a trend line model that gives a numeric value for a future/unknown data point.
• Classification: Predict a value/class/grouping for a person/company/entity based on data for other people/companies/entities.
• Clustering: Group items together based on similarities among these items.
• Dimension Reduction / Feature Selection / Factor Analysis: Determining which factors/dimensions of an entity are important in predicting a different value/dimension.
• Simulation: Coding a computer program to simulate a real life scenario.  Uses probabilities, if-then statements, etc.  After running this scenario thousands of times, the likelihood of any event can be determined.
• A/B (Hypothesis) Testing: Using statistical analysis to determine if a change/experiment has produced a significant difference in our target variable.
• Natural Language Processing: Using algorithms to analyze the words in a review, Tweet, email, or any text to determine the sentiment, subject matter, or anything else of interest we may want to find out.

These analyses can be ad hoc or operationalized into your system to provide automated analyses on the latest data available.  These can then be used in your reporting and/or added to your production data for more efficient products and services.  Examples of software to use in performing the above types of analyses include:

• R: an open source alternative to MATLAB,SAS, or SPSS.  Along with Python, the most popular programming language for doing data science.
• Python: another open source programming language for doing data science.  Along with R, it is the most popular programming language for doing data science.
• Octave: an open source version of MATLAB.  Not very widely used.
• MATLAB: a paid statistical programming language.  Still extremely popular and used in corporate and research settings.
• Excel: has basic statistical capabilities, but doesn't have more of the advanced analytics features.  Still, it is easy to use, widely available, and can do most things that most users need.
• Weka: data mining with a GUI.  Easy to use for exploring data and building classification models.  Free.
• SAS: still widely used, commercial analytics software.  Has its own statistical programming language.  Is decreasing in popularity due to R and Python.
• SPSS: IBM's commercial analytics solution.
• Azure Machine Learning: Microsoft's data science GUI based in its Cloud platform offerings. Easy to use and free to try, but must pay for more extensive use.

Step 6: Visualization

While all dashboarding involves visualization (and it may be the most common form of data visualization), not all visualization involves dashboarding.  For example, we often create one off visualizations (e.g., charts, graphs) that can be used in reports and presentations.  For most purposes, visualizations can be taken from a dashboard that have been sliced and filtered in a certain way to present a key insight.  However, sometimes more complex data visualizations will be needed that cannot be easily generated using a dashboard.  Such visualizations may require multiple layers in a graph or chart, creating infographics, generating a word cloud, and various other kinds of more complex visualizations. 

These kinds of visualizations are usually static (i.e., not regularly refreshing with a data feed) and are crafted and stylized more carefully and with more complexity.  The visualization is the end product, whereas with dashboarding, the visualization is a means to the end (which is the observation of status or discovery of key insights).

Here is a very incomplete list of some ways to visualize that are different from the above mentioned dashboarding tools:

• Programming languages:
• Examples:
• R: mentioned above, contains many packages for more complex visualizations, particularly related to statistical analysis, machine learning, and natural language processing, such as ggplot2, lattice, wordcloud.
• Python: mentioned above, also contains many packages for visualizations with matplotlib being the most well known.
• d3: a javsacript library for creating visualizations displayed in web browsers. Very popular. 
• Presentation software:
• Examples:
• PowerPoint
• Graphic Design:
• Example:
• Adobe Illustrator: along with other types of graphic design software, can be used to create visualizations that are not programmable or standardized.  Can bring together multiple visualizations into a single visualization.

Conclusion

How do you do analytics?  Like anything, it takes practice and study. If you are new to this field, dive in and start trying stuff.  Pick something in the above list that stands out to you, try it out, and read about it.  Then start to branch out into other areas as you try new things.  For the more seasoned veterans, read up on the latest updates, study up on the latest books and topics, take online courses or certificate programs to update your skills.  In other words, you do analytics by practicing and learning about it as you do it.

As I bring this series to a close, remember these things when doing analytics:

• Keep the end in mind: what is the purpose of your analytics?
• Understand who your stakeholders are and what beliefs, desires, and goals they have.
• Think about when you should and should not be doing analytics.
• Know where you should be doing analytics.
• Reflect on how you do analytics and always be open to new and better ways of doing it.

Good luck!

Philosophy of Analytics, Lesson Two: Who Are You Working For?

Introduction

In a previous post, I discussed the first lesson in a philosophy of analytics: begin with the end in mind.  That is, keep in mind the purpose of analytics when you are starting and designing and running an analytics project.  I defined the telos, the purpose, of analytics in the following way:

The purpose of analytics is to (1) justify or change beliefs with the use of evidence in the form of data  (2) in order to generate true (or truer) beliefs that can then be used to make decisions related to one's goals, and that, (3) because they are more in accord with reality, are more effective in bringing about one's goals.

This addresses the fourth of Aristotle's causes for an object: material, formal, efficient, and final.  In this post, I will address the efficient cause, that is, what brings about, creates, or changes the object.  In our context, the question we are discussing then is, what brings about, creates, or makes changes to analytics?  Who or what creates the data, who uses the data, who controls the data, who develops the analytics, and who uses the analytics?

A Little Action Theory

Before we answer that question, let's look at the purpose of analytics more closely.  Analytics is intended to justify or change beliefs, to generate true beliefs, to help make decisions to achieve goals.  Beliefs, decisions, and goals are held by agents with intentional states (i.e., people).  We can break each aspect down further:

• Beliefs: a person's beliefs relate to facts known by the person as well as assumptions made by the person, not necessarily supported by facts.
• Goals: a person's goals relate to what that person desires, that is, what that person wants.

The belief and goal (belief and desire pair) lead to a decision (action) on the part of an agent.

• Decision: a cognitive act which results in the taking of physical action or communication in accord with the belief-desire pair.

For example, suppose I want to eat an apple (goal/desire).  If I know that the grocery store sells apples (belief), then I can decide to go to the store to satisfy my desire to eat an apple.  Taking the action of going to the store and buying an apple will satisfy my desire, and it is the belief that the store has apples along with my desire to eat an apple that leads me to act.

Applying to Analytics

Why does this matter for analytics?  Well, since analytics is about changing/confirming beliefs so that decisions can be made in accordance with goals, we need to make sure we understand the who behind the beliefs, goals, and decisions:

• Beliefs: whose beliefs are we trying to change/confirm?  Maybe just as important, whose beliefs are we NOT trying to change/confirm?
• Goals:  whose goals are we trying to meet?  Whose goals are we NOT trying to meet?
• Decisions: who makes the decisions?  Who doesn't make the decision?

It is important that we keep each of these straight and separate, for they may not belong to the same person or group.  For example, suppose I am developing analytics for my manager.  We have data that will change or confirm his beliefs about customer sales.  He reports his belief to the CEO, who makes a decision to act in a certain way using my manager's belief.  The CEO makes this decision with the goals of the stockholders in mind in hopes of achieving the goals of the stockholders.  As one can see, there can be a lot of who involved analytics.

Who is Who?

Who is the who in an analytics environment?  That is, who or what brings about, changes, uses, or creates analytics? Perhaps this is a bit simplistic, but the following analytics flow is perhaps representative of most cases when boiled down to essentials in a business context:

1. Data source: the source of the data upon which the analytics will be done.  This can be machine generated (server logs) or people generated (customer sales transactions).  Perhaps the data is already stored in a server or data warehouse, and so this specific analytics project is a little downstream and can be seen as part of a larger analytics project (analytics within analytics).
2. Data administrators: those individuals whose job is to pull from the data source the data that is needed, clean it and transform it as needed.  Usually, this data will stored in a database.
3. Data warehousers: those individuals whose job is to take the data from the databases and create data warehouses that contain aggregates of data, summaries, calculated metrics, and KPIs.
4. Report/dashboard developers: those individuals responsible for developing reports, charts, dashboards, etc. that bring out the trends, metrics, and summaries of the data.
5. Analysts: those responsible for making sense of the data in the business context, spotting trends, noting key outliers, observing the metrics, and internalizing the overall business context.  These individuals use the reports and dashboards.
6. Belief Holder (Manager, Director, CEO): responsible for using the analysis of the data to inform his or her beliefs about the business context in order to communicate this belief to others.
7. Decision Maker (Manager, Director, CEO): responsible for using his or her beliefs about the business to make a decision about how to run the business.
8. Goal Holder (Manager, Director, CEO, Stockholders, Stakeholders): the ultimate stakeholder, the one whose goals and desires are to be achieved by the decision made on the basis of belief.

Notice something very important.  Persons 1-5 are usually thought of in the context of analytics.  However, the whole purpose of analytics rests with persons 6-8.  That means that there can be (and often is) a major gap (technologically, contextually, purposefully, etc.) between those who create, change, and bring about analytics and those who use analytics for its purpose.  For example, if I am a report developer, how can I make sure that the reports I am developing are useful if I don't know what the goals of the organization are?

Bridging the Gap

How is this gap bridged?  In the following way.  As the data, analytics, belief, decision, and goal flows from 1 through 8, the reverse also needs to be true.  The goals of the stakeholders need to be communicated to the decision makers, the decision to be made needs to be presented to the belief holder, and the beliefs to be tested or confirmed need to be communicated to the analyst and beyond.  In fact, the more that 6-8 can be communicated to 1-5, the better. For example, a data administrator that knows what the CEO cares about will know how to administer the data most effectively in accord with the CEO's goals.

Conversely, the more that 1-5 can be communicated to 6-8, the better.  A decision maker that doesn't appreciate the process that the data flows through, including its difficulties and limitations, will certainly not appreciate those who provide that data, nor will he or she fully understand the context of the decision to be made.  This can lead to undesirable results.  For example, a decision maker that has a true belief that customer sales are increasing rapidly may believe this to be true across the board.  However, if the data source excludes a certain kind of product, and this kind of product is in fact decreasing in sales, then any decision in regards to that product that assumes that it is increasing in sales will likely be a bad decision.

In short, communication is crucial.  Up and down the chain there needs to be constant communication about beliefs, goals, desires from 6-8 and technological/data-related specifics from 1-5.

The Analyst's Point of View

From the analyst's point of view, you need to know who cares about analytics.  Who are you working for?  What are his or her beliefs, goals, and decisions to be made?  What is most important to him or her in the business context?  Once you know this information, make sure your analytics, from start to finish, keep this in mind.  Again, begin with the end.  You are trying to represent the business context in the most realistic way so that those who are making decisions in accordance with the desired goals will have true beliefs about the business context.  Make sure your analytics are relevant to these beliefs, goals, and decisions.

Remember that the analytics you create need to be useable, not merely true.  If the analytics platform you provide is not understandable by the person using it, then it is not fulfilling its purpose.  Who cares if it is true if it is not useable?  Who cares how pretty it is if no one understands it?  My friend tells a story in which he created a beautiful and sophisticated dashboard for an executive.  The kinds of charts he used were perfectly selected to convey the needed information.  However, the executive could not make sense of the more sophisticated charts, and asked for a simplified version.  The lesson here is that you need to know your audience, and design your analytics for your audience.  Think about the user's perspective before designing your analytics so that when the analytics are complete, the users will actually use and understand your work.

Conclusion

In short, your analytics need to relate to the beliefs, goals, and decisions being made by those who use your analytics.  Furthermore, your analytics need to be useable by these individuals.  When your analytics target the beliefs needed to make good decisions in accordance with goals, and they are useable by those individuals informing beliefs, making decisions, and setting goals, then your analytics will fulfill their purpose, their telos.

Philosophy of Analytics, Lesson One: Begin with the End

Introduction

I have a Masters in Philosophy.  More specifically, I have a Masters in Analytic Philosophy, which is the method of philosophy most popular in the United States and the United Kingdom (as opposed to Continental/Existential/Phenomenological Philosophy).  When I began this blog, I titled it "Philosophical Analytics" to emphasize my interest in both philosophy and analytics (i.e., data related analyses and visualization) and my desire to continue to engage in both disciplines.

Recently, after reading the title of my blog, someone asked me what my philosophy of analytics was.  I had to think a while on this as I had not really formulated my impressions on doing analytics into well formed thoughts, principles, or assertions.  But this is a good question, a perfect question, for me.  This is the first of a series of blog posts that are an attempt to rectify that and to put forth my analytics philosophy thus far.

A Philosophy of Analytics

This blog is not about  how to build a predictive model in R, chart in Excel, or pull a query in SQL.  It's aim is more philosophical and methodological.  We could even call it "meta-analytics".  It will address the why or the why not behind the specific how.  Why should we create this dashboard? Why is this predictive model being used?  We are reflecting on the purpose of using various analytical tools and products.

But we can take a step back even further.  Why do analytics at all?  What is the purpose of analytics? How do we do analytics well?  The answers may be obvious to some, but others may have never asked these questions before.  We know that some people like shiny, flashy, and brightly-colored charts, graphs, slides, and dashboards.  They are impressed by regression lines and cool statistics.  But apart from the job security and budgetary victories that may be scored by throwing analytics left and right, what is the real point of analytics?

This blog post (and others like it) will focus on the nature of analytics: who uses it or does it, what it is, when is it appropriate to use, where should it be used, why is it used, and how best to use it.

Lesson One: Begin with the End

Aristotle specified four "causes" to account for or describe any object:

• the material cause: what the object is materially made of.
• the formal cause: how the object's material is arranged or shaped.
• the efficient cause: what brings about, creates, or changes the object.
• the final cause: the object's purpose, it's end.

Our object is analytics.  It is materially made of Excel sheets, Tableau dashboards, SQL queries, big data stores, R regressions, and Azure predictive models.  It's form consists of colors, lines, plots, and tables placed on billboards, websites, and desktops.  It is efficiently caused by developers from backend to frontend and by users that consume and provide feedback. But it's purpose?  What is it all about? In short:

The end, the purpose, the telos of analytics is this: data-driven decision making.

Why do we make charts or build models?  Why do we collect terabytes of data?  Surely not just because it's fun.  We do these things in order to gain insight into our domain of interest, to understand what is going on. Just because?  No!  We do this because we have to make decisions in our domain of interest, and we want to make good decisions. 

A business needs to understand what it's customers want through sales trends.  It needs to know how to allocate resources, where budgets need to be cut or expanded.  It does so by looking at its sales and financial data appropriately summarized and charted.  A politician needs to know where differing demographics stand on multiple issues so that he or she can most favorably present himself or herself to that demographic.  This is done through collections of voting records that have been grouped according to these demographics and along the lines of key issues.

Perhaps you are simply interested in learning more about a subject (as I often am), and perhaps your explorations have no immediate practical application.  Ok, fine.  Then we can describe the purpose of analytics in a more sophisticated way:

The purpose of analytics is to (1) justify or change beliefs with the use of evidence in the form of data  (2) in order to generate true (or truer) beliefs that can then be used to make decisions related to one's goals, and that, (3) because they are more in accord with reality, are more effective in bringing about one's goals.

 Let's break this down.  First, we are gathering data and presenting it to ourselves or to others to change or strengthen our beliefs about a given domain.  We are trying to understand what really is going on in the world, changing our beliefs about it if necessary.  If the data and subsequent analysis is good, then it will accurately represent reality in a useful way.  For example, we collect weather data and build models that predict what the weather will be like tomorrow so that we can have a true belief about the weather tomorrow.

Now why might that be important?  This leads to the second part.  We take our justified beliefs, supported by the evidence, to make decisions with regards to our goals. If I have the goal of having a good time while hiking outside, what I decide to wear outside will have a direct impact on whether I do have a good time if, contrary to my belief that it will be sunny, it in fact rains and I have decided to hike in a t-shirt and shorts.  If my belief were changed by the evidence that it would in fact rain, then I could make the decision to wear a jacket and have a more enjoyable time.

And this leads to the third part, that data supported decisions are more effective in bringing about our goals. We use data to build a model of reality in a specific domain, and then using that model to represent reality, we make a decision that is lived out in reality.  In the case above, I would look at the data related to weather patterns and historical trends along with the predicted outcomes for what the weather will be like for my hike.  Because the data and models suggest that it will rain, I make the decision to wear and rain jacket.  Consequently, when it does rain, I am not soaked and I still have a good time hiking (which I would not have had if I had gotten soaked).

The goal of my hike was to have a good time.  And by using the analytics related to weather to inform my choice of clothing, I was able to have a good time.  The data and models enabled my hike to be successful, that is, effective, in bringing about my goal.  I was empowered to make a decision more in accord with reality precisely because I had evidence to support my belief that it was going to rain.

Putting It Into Practice: What is Your End?

Ok, so the purpose of analytics is data-driven decision making, that is, to justify/change beliefs that lead to decisions that accomplish one's goals.  So what?  Well, thinking about this purpose of analytics can radically change how you approach your analytics projects.  Most importantly, if the point of analytics is to help one to accomplish one's goals, then before any analytics project can be undertaken, this question must be answered: what are the goals?

Have any of you been told to look at the data, build a dashboard, create a model, and then report back with what you find?  That's like being put into a closet filled with junk and told to find something useful.  What is useful?  It all depends on what one's goals or aims are.  Any number of items may be useful, but they will be useful with respect to certain goals (and not others).

In a business, we can always tie it back to money: increasing profit/revenue/sales or decreasing expenses.  But let's be more specific.  In fact, be as specific as possible.  For your organization, how does it make money specifically?  What role does it play in the larger context of the company?  What are the specific goals of your organization?  What decisions need to be made that could use better data to drive those decisions?

Perhaps your organization saves money by improving code efficiency.  Perhaps your team increases sales by reducing transaction times.  Maybe you improve revenue by increasing the conversion rate of sales through the company website.  Whatever it is, think about the specific goals of your team/organization/company, and then plan your analytics solution to capture, measure, and display the progress in meeting those goals.

Suppose that your organization's goal is to improve click-through rates on the website. Once you know that, you know that you need to gather data related to clicks and visits by users, locations, dates.  And you know that you need to calculate the click-through rate and display this over time (perhaps a line graph) to determine if the organization is improving in meeting its goal. You gather the data with sufficient granularity so that locations that are lagging in click-through rates can receive targeted investment.   Other important decisions can be informed by the data that you have gathered.

Without having this specific goal in mind, you would have no idea what data to gather, what measures to calculate, or what visualizations to create.  And your project wouldn't go anywhere or provide any business value to anyone.

Conclusion

You wouldn't begin a journey without a destination, right?  So don't begin an analytics project without a destination, a specific goal, in mind.  Otherwise, you will wander about aimlessly for a time in the sea of data before your project is cancelled.  Instead, figure out what the end, the purpose, of your analytics will be, and then figure out how to concretely get there.

Before you start, begin with the end.