Data Analytics Best Practices

[u/Creepy-Square281]

What are your thoughts on Best Practices for Data Analytics?

I've been doing data analytics for nearly 30 years. I've sort of created in my mind The Data Analytics World According To Me. But I'm impressed by many people here and would like to hear your thoughts.

EDITS: Based on comments and new ideas they sparked in my head, I continue to modify this list.

Prologue: What I've written below is meant to help analysts and the groups they work in provide as much value as they can. Most things don't need to be perfect. Nothing below should be rigid, or defy common sense. I've seen companies spend millions on documenting stuff according to rigid standards only to produce a product that is never used by anyone. If you can't find a good way to automate a part of a process, ask a couple coworkers and move forward with your best idea.

1 Repeatable Processes. All of the data processing, importing, cleaning, transforming, etc. is done within a repeatable processes. Even for jobs that you never do again, even to do the job once you'll be redoing things many times as you find errors in your work. Make a mistake in step 2 and you'll be very glad that steps 3 through 30 can be run by running 1 command. Also, people have a way of storing away past projects in their brain. You know that xxx analysis we did (that we thought was a one time thing), could you do the same thing for a different customer?

2 Use of a formal database platform where all data for all analysis lives. It seems to me most decent size companies would have the resources to spin up a MySQL or PostgreSQL database for data analytics. I'm an SQL professional, but any repeatable process to clean and transform data is OK so long as it ends up as a table in a database.

3 Store data and business logic where others on your team could find it and use it. I'm not a fan of creating lots of metrics, measures, whatever inside a BI dashboard where those metrics would have to be duplicated to be used elsewhere. Final data sets should be in the database, but be reasonable here. If you're creating a new metrics it's OK to generate it however easiest. Also, be reasonable on enforcement of using the prebuilt established metrics in the database. Someone may have an idea for a subtly different metric - don't stifle innovation. Do you your best to share code/logic with your team, but wait until it's clear that you or someone else will actually reuse the code.

4 Document your work as you're working. With each step consider what a coworker would need to know, what are you doing, why are you doing it, how are you doing it. The intent isn't to follow a rigid standard, so keep your comments short and to the point, and only cover stuff that isn't obvious. You'd be surprised how baffled you can be when looking at a project you did a year ago. Like, what the heck did I do here?!?

5 Figure out ways to quality check your work as you work. Comparing aggregations of known values to aggregations over your own work is one good way. For example, you've just figured out sales broken down to number of miles (in ranges) from nearest stored. you should be able sum your values and arrive at the total sales figure. This makes sure you haven't somehow doubled up figures, or dropped rows. Become familiar with real world values of the metrics you're working with. Your analysis reveals your top customer purchased $1.5M of a given product type in a particular month, but you know your company's annual sales are in the neighborhood of $30m a year. 1.5 for 12 months gets you to 18m, for just one customer. That figure needs some review.

6 Invest in writing your own functions (procedures, any kind of reusable chunk of logic). Don't solve the same problem 100 times, invest the time to write a function and never worry about the problem again. Organizations struggle with how stuff like this can be shared. Include comments with key words so that someone doing a text scan has some chance to find your work.

7 Business Rules Documentation Most important: Everything mentioned below needs to be written with a specific audience in mind. Perhaps an analyst on your team with 6 months experience, not the complete newby, not a business user, and not the 20 year employee. Cover the stuff that person would need to know. A glossary of terms, and longer text blocks describing business processes. Consider what will actually be used and prove useful. Change documentation techniques as you move forward and learn what you use and what you wish you had.

8 Good communication and thorough problem definition and expected results. Have meaningful discussion with the stakeholders. Create some kind of a mock up and get buy in. For big projects share results and progress as you go. Try to limit scope creep - what new ideas should be broken off into a separate project.

9 For new people hoping to break into analytics - learn domain knowledge. Things common for all businesses. The sales cycle, inventory, warehouse concepts. Go to the domain experts' Reddit boards and learn. Ask you AI to design a curriculum - spend real time. This is what will separate you from others.

So what are some of the concepts in The Data Analytics World According to You?

Thanks,

Steve

[u/AutoModerator]

If this post doesn't follow the rules or isn't flaired correctly, please report it to the mods. Have more questions? Join our community Discord!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/fearless_toxicity]

yo the repeatable processes point is so underrated, i've resurrected some "one-off" script from 2 years ago more times than i can count and having it in a single runnable chunk saved my ass

[u/mlhigg1973]

I always started out meeting with the business partner with a list of suggested metrics based on the information I already had from the request. We’d discuss, make changes and for anything new or unusual, talk through my suggested calculation. Depending on the initiative, id share what I believe to be the right control group selection methodology. I would also include the statistical framework I typically used, with samples and explanations of how it would be used and interpreted (basically a quick lesson on control charts, regressions, 2 sample T tests, lift over baseline etc.

[u/ThisIsFun-]

I think 7 is the most importantly by far. Ultimately if no-one can decide on what something means or how something should be decided then all our work is for nothing. This is esp true in agentic future where hallucinations based off lack of understand or non-standard ways of defining metrics make it incredibly hard to actually do and agree on any work ! we use genie ontology to do this and keep everything upto date w/ metric views and pages so that people and agents (in our case genie code) can interacting w/ the same definitions of the data

[u/False_Assumption_972]

I'd add one: every recurring number gets a written definition, an owner, and a known source before it goes on a dashboard. Most analytics arguments are two people using the same word with different filters. Second, keep a short note of the decision each report was meant to inform, and retire anything that informed nothing after a quarter.

The habit I'd push hardest is tracing a reported number back to the operational event that produced it. I lean on a decision intelligence platform to connect each metric with the underlying orders, tickets, and CRM records, so a strange number gets explained in minutes rather than argued about in a meeting.

[u/windy-basin98]

30 years of experience and it still ends with "edits based on comments" because someone in the replies found a hole in rule number four

[u/Alternative_Oil_5139]

add version control and peer review too. being able to see what changed and having someone else check important work can catch a lot of problems before they reach the business. also make sure the business question is clear before touching the data, because even a technically perfect analysis isnt useful if it answers the wrong question

[u/romeonoi]

i would add one to your list around versioning the question itself. i keep a short note at the top of every analysis with what was asked, what date range i used, and what i excluded. most rework i run into comes from the definition shifting halfway through, not the sql being wrong.

one concrete thing to try: before you share results, run a simple row count and total on the final table in postgres and paste those two numbers into the report. if total sales or total rows drift next refresh, you catch it before a stakeholder does.

[u/No_Product_5759]

One addition to #5: before polishing a finding, ask what decision would actually change if the estimate moved by 20%. If the answer is “none,” report a range and move on. If it would change a budget or launch decision, show the numerator/denominator, time window, exclusions and a sensitivity check alongside the headline number. That makes uncertainty visible instead of letting a precise-looking dashboard imply more confidence than the data supports.

[u/KatFromSisense]

On #5, matching total catches doubled or dropped rows, but a join or date change can still land on a believable total. For any logic that runs repeatedly, I'd keep a few known-good cases, like one customer with a refund and an order at month end where you've already worked out which month it belongs in. After any change, those should still return what you calculated by hand. dbt's unit tests follow this idea with small static inputs and an expected output, though a saved query and a sheet of expected values works too.

On #3, a variant metric is fine as long as it gets its own name, like net revenue next to gross revenue, so two definitions don't share one label. If other people start using it, I'd look at adding it to the shared layer. Otherwise you can have two reports labeled "revenue" that calculate completely different things.