HackIndia Logo
HackathonsNewsSkillsGrowth
HackIndia LogoContact: +91 9910125804

General

  • Companies
  • Colleges
  • Board of Advisors
  • Brand Ambassadors
  • FAQ
  • Contact
  • Report a Bug

Hackathons

  • Upcoming Hackathons
  • Judges
  • Mentors
  • Partners
  • Participating Colleges
  • Testimonials

Resources

  • About Us
  • Branding
  • Latest News
  • Growth
  • Skills
  • Builders
  • Ecosystem
  • Forum
  • Ideas
  • Prompt Optimizer
  • Games

© 2026 HackIndia. All rights reserved.

Privacy PolicyTerms of ServiceCode of ConductSitemap

Build 2.139 · 05 Nov 2026, 10:27 UTC

    HackIndia
    HackathonsNewsInternshipsSkillsGrowthPro Perks
    ← Use Stats Without Misleading

    All the reading

    Statistics

    8 lessons, about 36 minutes. The check's questions come from these.

    Contents
    Reading averages and shapes
    1. 1. Spot Misleading Averages
    2. 2. Understand Data Shapes
    Checking samples and causation
    1. 3. Check Your Sample
    2. 4. Separate Link From Cause
    Testing claims and reporting evidence
    1. 5. Run A Simple A/B Test
    2. 6. Read Charts Sceptically
    3. 7. Build Your Evidence Section
    4. 8. Submit The Data-Backed Project

    Reading averages and shapes

    1. Spot Misleading Averages

    4 min

    In 30 seconds
    • Tell when an average hides what users actually experienced.
    • Compare mean and median before writing a data insight.
    • Add one honest limitation to an average-based claim.
    Key point

    One idea

    An average is a summary, not the full story. Before you claim a number proves something, check whether a few extreme values are pulling it up or down.

    Why this matters

    Hackathon projects often show numbers like average wait time, average spend, average score, or average study hours. These are useful, but they can mislead recruiters, judges, and users if the data is uneven.

    Your job is not to avoid averages. Your job is to use them with judgement.

    Mean vs median

    The mean is what most people call the average: add all values, then divide by count. The median is the middle value after sorting.

    If the mean and median are close, the average is usually okay as a quick summary. If they are far apart, say why before making a claim.

    Example

    UPI wait example

    Say your project tracks payment confirmation time for 9 UPI transactions in a campus canteen. One transaction was delayed because the network dropped.

    The mean says users waited about 18 seconds. The median says a typical user waited 7 seconds. Both are true, but they tell different stories.

    times = [5, 6, 6, 7, 7, 8, 9, 10, 105]
    
    mean = sum(times) / len(times)
    sorted_times = sorted(times)
    median = sorted_times[len(times) // 2]
    
    print("mean:", round(mean, 1))
    print("median:", median)
    
    # Output:
    # mean: 18.1
    # median: 7
    Common mistake

    2. Understand Data Shapes

    4 min

    In 30 seconds
    • See the shape of data before you write an insight.
    • Use histograms and box plots to spot skew, clusters, and outliers.
    • Explain what the shape changes about your claim.
    Key point

    Shape beats one number

    A dataset has a shape. The shape tells you if most values are packed together, spread out, split into groups, or pulled by a few extreme values.

    Before you claim “users finish in 4 minutes” or “students spend ₹200”, look at the full distribution. Your insight should match the shape, not just the centre.

    What to look for

    A histogram shows how often values fall into ranges. A box plot shows the middle half, the median, and possible outliers.

    For hackathon work, look for four things: skew, outliers, clusters, and range. These usually change the story.

    Your to-do

    Read the shape

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    Checking samples and causation

    3. Check Your Sample

    5 min

    In 30 seconds
    • Judge whether your sample matches the group you want to talk about.
    • Describe how you collected data, who is missing, and why it matters.
    • Add a sample note to your hackathon project so your insight stays honest.
    Key point

    The sample is the claim

    Your insight is only about the people, events, rows, or products your sample can fairly represent.

    If you collected responses from 42 students in your own WhatsApp groups, do not write “Indian students prefer X”. Write “In our sample of 42 college students, mostly from our network, X was common”.

    Population vs sample

    The population is the full group you want to talk about. The sample is the part you actually observed.

    For a hackathon project, your population might be “students using UPI for canteen payments”. Your sample might be “78 students from two colleges who answered our form”.

    Your to-do

    Check sample fit

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    Testing claims and reporting evidence

    5. Run A Simple A/B Test

    5 min

    In 30 seconds
    • Choose one metric before you compare two versions.
    • Randomly split users so Version A and B get a fair test.
    • Report the result with sample size, effect, and a limitation.

    Why this matters

    In a hackathon, you may test two button labels, onboarding screens, prompts, or recommendation rules. An A/B test helps you compare them without just trusting vibes.

    You are not trying to prove a big truth. You are trying to make a small, honest claim like: “In our sample, version B got more sign-ups than A.”

    Key point

    Single idea

    Change one thing, choose one metric, and split people randomly. If you change many things or pick the metric after seeing results, your test becomes a story, not evidence.

    Your to-do

    Set up the test

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    10 questions, 7 to pass.

    Sign in to take the test

    Common mistake

    Do not write: “Our app has an average UPI wait time of 18 seconds, so the experience is slow.” That ignores the shape of the data.

    Better: “Most payments completed in 5 to 10 seconds, but one 105-second delay increased the mean to 18.1 seconds. Median wait time was 7 seconds.”

    Tip

    Use AI carefully

    You can ask ChatGPT, Gemini, or Claude to explain your average in plain language. Paste the numbers and ask it to compare mean and median.

    Check the answer yourself. Make sure it does not turn one small dataset into a big claim about all users, all colleges, or all of India.

    Prompt:
    Here are wait times in seconds from 9 test transactions: 5, 6, 6, 7, 7, 8, 9, 10, 105.
    Calculate the mean and median. Write one honest insight and one limitation for a hackathon README.
    Your to-do

    Average check

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    0 of 5 done

    Example

    Plot your column

    Use this on a CSV from your project. It could be response time, order value, study minutes, delivery distance, or app session length.

    Ask an AI tool to help adapt the column name, but check that it did not change your data or silently remove rows.

    import pandas as pd
    import matplotlib.pyplot as plt
    
    # Example: survey.csv has a column called session_minutes
    df = pd.read_csv("survey.csv")
    
    print(df["session_minutes"].describe())
    
    plt.hist(df["session_minutes"].dropna(), bins=10)
    plt.xlabel("Session length in minutes")
    plt.ylabel("Number of users")
    plt.title("Distribution of session length")
    plt.show()
    
    df.boxplot(column="session_minutes")
    plt.ylabel("Minutes")
    plt.title("Session length box plot")
    plt.show()
    Common mistake

    Do not hide tails

    A common mistake is to report only the average when the data has a long tail. If most users finish in 2 to 5 minutes but two users took 45 minutes, the average may sound too high.

    Another mistake is deleting outliers because they look ugly. First ask why they exist. A 300-minute session may be a bug, an idle tab, or a real power user.

    Tip

    Use plain labels

    Your chart title should say what is measured, not what you want to prove. Use “Distribution of checkout time” instead of “Our checkout is fast”.

    In your submission, pair each chart with one honest sentence: “Most sessions are under 5 minutes, but a few long sessions pull the average up.”

    Example

    Better insight

    Weak insight: “Average study time is 62 minutes, so students study for about an hour.”

    Better insight: “Most students in our sample studied for 20 to 40 minutes. A few 3-hour entries pulled the average up, so the median is a better summary for this feature.”

    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    0 of 5 done

    Common mistake

    Common overclaim

    Beginners often treat easy data as if it represents everyone. This is convenience sampling. It is fine for a hackathon if you label it clearly.

    Do not hide it. Recruiters trust a builder who says “our sample is biased toward engineering students” more than one who makes a big claim from a small form.

    Example

    Sample note example

    Add a small note beside your chart or in your README. This turns a weak claim into an honest one.

    Here is a simple project note for a canteen payments feature.

    Dataset / sample
    Source: Google Form shared in 3 college WhatsApp groups.
    Rows: 78 responses collected on 12 Jan 2026.
    Who is included: Mostly engineering students from Pune and Bengaluru.
    Who may be missing: Non-engineering students, cash-only users, students not active on WhatsApp.
    Use this for: Early product direction and demo decisions.
    Do not use this for: Claiming behaviour of all Indian college students.
    Insight: In this sample, UPI was the most common canteen payment method.
    Limitation: The sample is small and biased toward our own network.
    Tip

    Use AI carefully

    You can ask ChatGPT, Gemini, or Claude to inspect your sample description before submission.

    Paste only non-sensitive summary details. Check that the AI does not invent representativeness, percentages, or a population you did not measure.

    Prompt:
    I am submitting a hackathon project with this sample note. Tell me if my insight overclaims beyond the sample. Suggest a safer wording.
    
    Sample note:
    [Paste your note]
    
    Insight:
    [Paste your insight]

    What good looks like

    A good sample section is short. It says source, size, time, included groups, missing groups, and a safe claim.

    You do not need a perfect random sample for a hackathon. You need a clear boundary around what your data can and cannot say.

    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    4. Separate Link From Cause

    5 min

    In 30 seconds
    • Tell the difference between correlation and causation in your project evidence.
    • Name likely confounders before you write an insight.
    • Write safer claims that recruiters and judges can trust.
    Key point

    One idea

    A link in your data does not prove one thing caused the other. It only says two things moved together in your sample.

    Use causal words like “caused”, “improved”, or “reduced” only when your design supports it, such as a planned A/B test or a strong comparison.

    Link versus cause

    A link is a pattern. For example, students who used your timetable app more often also reported fewer missed classes.

    A cause is a stronger claim. It says using the app led to fewer missed classes. That needs more evidence because other reasons may explain the pattern.

    Common mistake

    Common overclaim

    Beginners often turn a chart into a story that sounds stronger than the data. “Users who saved goals completed more tasks, so goal saving increases productivity” is too strong if users chose the feature themselves.

    Maybe serious users were already more productive. Maybe final-year students used the feature more. Maybe people who had fewer labs had more time to complete tasks.

    Your to-do

    Check confounders

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Example

    Safer insight

    Suppose your hackathon project studies whether reminder notifications are linked with assignment submission. Your data is observational because users turned reminders on by choice.

    You can still share a useful insight. Just avoid making it sound like a proven cause.

    Data summary:
    - 120 student users
    - 52 turned reminders on
    - 68 left reminders off
    - 38% of reminder users submitted before the deadline
    - 21% of non-reminder users submitted before the deadline
    
    Too strong:
    Reminders increased early submissions by 17 percentage points.
    
    Safer:
    In our sample, users who turned reminders on had a higher early-submission rate, 38% versus 21%.
    This does not prove reminders caused the difference because users chose whether to enable them.
    A possible confounder is study discipline or workload.
    Tip

    Use AI carefully

    You can ask ChatGPT, Gemini, or Claude to help rewrite your insight. Do not ask it to “make the result sound impressive”. Ask it to make the claim honest.

    Check the output for banned causal words. If your data was not an experiment, replace “caused”, “led to”, and “improved” with “was linked with”, “was associated with”, or “in our sample, users who…”

    Prompt:
    Rewrite this project insight so it does not claim causation. Keep numbers. Mention one limitation.
    
    Insight:
    Users who enabled reminders submitted earlier, so reminders improved deadline behaviour.
    
    Data:
    38% early submission with reminders, 21% without reminders. Users chose whether to enable reminders.

    When cause is stronger

    You get closer to cause when you control who gets what. For example, randomly show reminders to half of new users and compare early submissions.

    That is lesson 5. For now, your job is to label ordinary project data honestly. Say what you observed, name what else could explain it, and avoid overclaiming.

    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Example

    Tiny split script

    For a web project, assign a visitor once and save it in localStorage. This is enough for a demo, but not for serious production analytics.

    Log the group and outcome to your backend, Google Sheet, Supabase table, or a CSV export. Check that both groups got similar numbers of users.

    // Browser JS: assign A or B once per visitor
    let variant = localStorage.getItem("variant");
    
    if (!variant) {
      variant = Math.random() < 0.5 ? "A" : "B";
      localStorage.setItem("variant", variant);
    }
    
    // Example use
    const button = document.querySelector("#submitBtn");
    button.textContent = variant === "A" ? "Submit" : "Get result";
    
    // When the user completes the action, log:
    // { variant: "A", completed: true }
    Common mistake

    Do not peek too much

    Beginners often check results after every few users and stop when B looks ahead. That makes random luck look like a win.

    For a hackathon, decide a simple stop rule first. For example: “We will compare after 40 total users or at demo time, whichever comes first.”

    Example

    Read the result

    Use counts first. Percentages without counts can mislead, especially with small samples.

    Here is a simple result you could put in your evidence section.

    A: 9 completions out of 25 users = 36%
    B: 14 completions out of 27 users = 52%
    Difference: B is 16 percentage points higher
    Plain-language insight: In this sample, "Get result" had more completions than "Submit".
    Limitation: The sample is small and mostly came from hackathon friends, so it may not represent real users.
    Tip

    Use AI carefully

    You can ask ChatGPT, Gemini, or Claude to help phrase the insight. Give it the counts, not just the percentages.

    Check that it mentions sample size, does not say “proved”, and includes a limitation. Replace confident claims with “in this sample” or “suggests”.

    Prompt:
    Rewrite this A/B test result in plain language for a hackathon README.
    Counts: A had 9 completions out of 25 users. B had 14 completions out of 27 users.
    Do not claim causation beyond this test. Mention one limitation.
    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    6. Read Charts Sceptically

    4 min

    In 30 seconds
    • Check whether a chart supports the claim written above it.
    • Spot axis tricks, missing context, and chart types that confuse.
    • Fix one chart in your project so it is honest and easy to read.
    Key point

    One job

    A chart is evidence, not decoration. Read the title, axes, scale, labels, and source before you believe the claim.

    Your question is simple: does the chart make the difference look bigger, smaller, or clearer than the data deserves?

    Start with the claim

    Most misleading charts begin with a sentence like “Our feature doubled engagement.” The chart may only show a tiny sample, a short time window, or a change from 2 users to 4 users.

    Do not fight the chart first. First write the claim in plain words. Then check if the chart has enough information to support that claim.

    Your to-do

    Read it in order

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Common mistake

    Axis traps

    A bar chart should usually start at zero. If it starts at 80, a small difference can look huge. This is common in pitch decks and college project posters.

    Line charts can use a non-zero y-axis when the goal is to show movement over time, but the scale must be clear. Never hide the baseline to make your result look better.

    Example

    Fix the chart data

    Suppose your hackathon app tracks weekly sign-ups from two colleges. This CSV is small, but it is honest because it shows counts, dates, and groups.

    You can chart it with any tool later. The important part is that the reader can see what was measured.

    week,college,signup_count
    2026-01-05,College A,42
    2026-01-12,College A,47
    2026-01-19,College A,51
    2026-01-05,College B,39
    2026-01-12,College B,40
    2026-01-19,College B,44
    Tip

    Use AI carefully

    You can ask ChatGPT, Gemini, or Claude to review your chart. Paste the chart title, axis labels, data table, and the claim. Ask: “What could mislead a reader here?”

    Check the answer yourself. AI may suggest problems that do not apply, or miss the main issue: unclear sample, missing baseline, or a claim that goes beyond the data.

    Better chart choices

    Use a bar chart for comparing categories, like sign-ups by referral source. Use a line chart for change over time, like daily active users across two weeks.

    Avoid 3D charts and pie charts with too many slices. If your reader needs to calculate in their head, use a simpler chart or add labels.

    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    7. Build Your Evidence Section

    5 min

    In 30 seconds
    • Turn your dataset, chart, insight, and limitation into a clear evidence section.
    • Write claims that match your sample, not what you wish the data proved.
    • Add a small evidence file to your repo so judges and recruiters can verify it.
    Key point

    One honest claim

    Your evidence section should help a reader answer one question: what did you learn from your data, and how strong is that learning?

    Do not try to sound scientific. Show the data source, chart, insight, and limitation in plain words.

    What it contains

    For your HackIndia submission, your evidence section needs four parts: dataset or sample, at least one chart, one plain-language insight, and one clear limitation.

    This can live in your README, project report, or a separate file like EVIDENCE.md. A public repo makes it easier to check.

    Your to-do

    Build the section

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Common mistake

    Common overclaim

    A weak evidence section says: “Students prefer our feature.” That sounds bigger than the data.

    A better claim says: “In our 42-response college survey, more respondents picked reminders than streaks as the most useful feature.” This keeps the claim inside the sample.

    Example

    Repo file example

    Create a small EVIDENCE.md file like this. Keep it short. Judges do not need a full research paper during a hackathon.

    # Evidence
    
    ## Dataset or sample
    We used 42 responses from a Google Form shared with students from our college WhatsApp groups on 18 Jan 2026.
    The anonymised CSV is in data/survey_responses.csv.
    
    ## Chart
    See charts/feature_preference.png.
    It shows how many respondents chose each feature as most useful.
    
    ## Plain-language insight
    In this sample, reminders were chosen most often. This supports making reminders the default feature on the home screen.
    
    ## Limitation
    This was a small convenience sample from our own college network. It may not represent students from other colleges, working users, or people who did not answer the form.
    Tip

    Use AI carefully

    You can ask ChatGPT, Gemini, or Claude to rewrite your evidence section in simpler language. Paste your draft and ask it to reduce overclaiming.

    Check every number, file name, and limitation it returns. AI often makes wording smoother, but it can also make claims sound stronger than your data supports.

    Prompt:
    Rewrite this evidence section in plain language for a hackathon README.
    Do not add new facts.
    Keep the claim limited to this sample.
    Point out if any sentence overclaims.
    
    [Paste your evidence section here]
    Example

    Claim strength check

    Before you submit, compare your wording to your sample. Use cautious words when your data is small, biased, or observational.

    Too strong:
    Our app improves student productivity.
    
    Better:
    In our 15-user test, 11 users completed the task faster with reminders turned on.
    
    Too strong:
    Indian students want UPI rewards for learning.
    
    Better:
    Among 38 respondents from our campus survey, UPI cashback was the most selected reward option.
    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    8. Submit The Data-Backed Project

    4 min

    In 30 seconds
    • Package your data work so judges and recruiters can inspect it fast.
    • Submit one chart, one plain-language insight, and one honest limitation.
    • Add links and files that prove your claim without making people guess.
    Key point

    Your proof bundle

    A data-backed project is not just a chart in your demo. It is a small proof bundle: dataset or sample, chart, insight, limitation, and a link to the code that made it.

    Make it easy to verify in under two minutes. Judges and recruiters should not need to DM you for the CSV.

    Your to-do

    Before you submit

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    What counts

    Your dataset can be small. It can be 50 survey responses, scraped public data, app usage logs from your demo, or a manually labelled sample.

    Do not hide weak data. If your sample is only from your college WhatsApp groups, say that. Honest limits show judgement.

    Example

    README evidence block

    Use a short section like this in your README. Replace the details with your own project data.

    Evidence
    
    Dataset or sample:
    - File: data/feedback_sample.csv
    - Rows: 83 student feedback responses collected during testing
    - Columns: timestamp, college_year, task_completed, rating, comment
    
    Chart:
    - File: reports/task_completion_by_year.png
    - What it shows: completion rate by college year
    
    Plain-language insight:
    - In our small test, second and third year students completed the onboarding task more often than first year students.
    
    Limitation:
    - The sample came from our own college network, so it may not represent students from other colleges or cities.
    
    How to reproduce:
    - Run: python scripts/make_chart.py
    Tip

    Use AI carefully

    You can ask ChatGPT, Gemini, or Claude to draft your evidence section from your CSV summary. Give it row count, column names, chart title, and your rough finding.

    Check the output for overclaiming. Replace words like “proves”, “always”, and “users prefer” with safer words like “suggests”, “in this sample”, and “we observed”.

    Common mistake

    Do not submit vibes

    A sentence like “users loved it” is not a data-backed insight unless you show what data supports it.

    Also avoid a lonely chart with no explanation. A chart needs a claim and a limitation, or people will fill in their own story.

    Your to-do

    Submission checklist

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done

    Your to-do

    Do this now

    Do each one yourself, then tap it to tick it off. The ticks are only a checklist for you: they are not marked or scored.

    0 of 5 done