Product analyst job description template

A job description for a fresher product analyst, with an intern version, screening questions and the signals that show a candidate can turn product data into a clear answer.

In short

A fresher product analyst writes SQL on event and user tables, tracks sign-up, activation and retention, keeps dashboards correct, checks that tracking events fire, reads A/B test results with a senior where the team runs them, and writes short insight notes. Ask for SQL, spreadsheet skills, familiarity with one BI tool, an understanding of funnels and cohorts, and clear writing. Python is optional; machine learning is not needed.

Product analyst job description template

Fill in your company details once and both versions below update: the full-time job for freshers and the internship. Copy the one you need into your job post.

Nothing you type leaves this browser.

1. Full-time product analyst (fresher)

Product analyst (fresher)

Company: [Company name]
Location: [Location] · Work mode: [Work mode]
Employment type: Full-time
CTC: [CTC for the full-time role]
Joining: [Joining date] · Apply by: [Apply by]

About [Company name]

[About your company]

About the role

[Company name] is hiring a fresher product analyst for the [Team] team. The job is to help the product team see how people use our product: which steps they finish, where they stop and whether they come back. You will write SQL on event and user tables, keep dashboards correct, check new tracking with engineers and write short notes for product managers. A senior analyst reviews your work and shows you how we define each metric.

What you will do

  • Write SQL on event and user tables to answer product questions, such as the number of new users who completed the first key action within a week of signing up
  • Track the product’s core metrics, such as sign-ups, activation, retention and funnel conversion, and write each definition down: what counts, over which period and from which table
  • Build and refresh dashboards in the team’s BI tool, and compare their totals with the source tables before anyone relies on them
  • Check with engineers that new tracking events fire correctly: test them on a staging build or test account, confirm names and properties, and report events that are missing, sent twice or carrying the wrong properties
  • Break down a metric that moved, such as last week’s active users, by source, platform, app version, city and new versus returning users, using the team’s definitions, and note what the data shows and what it cannot show
  • Build cohort and retention tables, for example users grouped by sign-up week, and point out the group that behaves differently
  • Read A/B test results with a senior, where the team runs them: check that users were split at random, that both groups ran over the same dates and that the metric was chosen before the test, then report the numbers without calling a winner early
  • Answer product managers’ questions in a short insight note that gives the question, the finding, the evidence and a suggested next step
  • Keep a metric dictionary and a list of known data issues, so a colleague can repeat an analysis and every team uses the same definitions
  • Work only with data you are cleared to use, and keep names, phone numbers and email addresses out of dashboards and notes unless the team’s data policy allows them

What we are looking for

  • SQL on a table of events or orders: SELECT, WHERE, JOIN and GROUP BY, plus a first window function such as ROW_NUMBER or LAG, learnt in a course, a lab or a project
  • Spreadsheet skill in Excel or Google Sheets: pivot tables, lookups and charts, enough to cross-check a SQL result
  • Hands-on use of one BI tool, such as Power BI, Tableau, Looker Studio or Metabase, to build a dashboard with filters
  • Product sense: you can explain a funnel, a cohort, activation and retention in plain words, with an example from an app you use
  • Care with numbers: you compare a result with a second source, notice a count that looks too high or too low, and know why a small or lopsided sample can mislead
  • Clear writing: a finding, its evidence and its limits in a few lines that a non-technical reader can follow
  • One project or case study on real or sample data that you can walk us through from question to finding, or describe if the work is private

Good to have

  • Python with pandas for event files too large for a spreadsheet
  • Use of an event analytics tool such as Mixpanel, Amplitude or Google Analytics
  • A basic idea of A/B testing: control and variant groups, sample size and a metric chosen in advance
  • Reading or drafting a tracking plan, the list of events and properties a feature should send
  • Close knowledge of one kind of product, such as food delivery, learning apps, payments or online shopping, from a project or from using it closely

Who can apply

Final-year students and graduates of any stream can apply, including B.Tech, BCA, B.Sc, BCom, BBA, MBA, MCA and M.Sc. The role rewards clear questions about product data more than any particular degree, so shortlist on SQL and one analysis the candidate can explain.

How to apply

Apply through this job post by [Apply by]. Shortlisted candidates will hear from us about the next steps.

2. Product analyst internship

Product analyst intern

Company: [Company name]
Location: [Location] · Work mode: [Work mode]
Employment type: Internship · Duration: [Internship duration]
Stipend: [Stipend for the internship]
Joining: [Joining date] · Apply by: [Apply by]

About [Company name]

[About your company]

About the role

[Company name] is looking for a product analytics intern to work with a mentor on one product question at a time. You will write SQL on sample data, build a funnel, check new tracking events against a plan and write short notes for the product team. You will not use live customer records or own a metric alone. Any publication or portfolio use of your work needs approval from [Company name].

What you will do

  • Draft a tracking plan for one small feature, listing each event, its properties and when it should fire, and have an engineer review it
  • Test the new events with sample users on a test account or staging build, against that plan, and list what matched and what did not
  • Write SQL, checked by your mentor, on made-up sample data, or on a copy the data owner has approved with personal details removed, to answer one question, such as the number of new users who reached the first key action
  • Build a funnel from sign-up to first order (or first lesson) on sample data and mark the step where the largest number of users drop off
  • Make a retention table on the sample data for one sign-up month and write three lines on what it shows
  • Write one insight note for the product team from the sample data and present it, saying where each number comes from

What we are looking for

  • A student or recent graduate from any stream, such as B.Tech, BCA, B.Sc, BCom, BBA, MBA or MCA
  • Introductory SQL from a course or college lab: SELECT, WHERE, JOIN and GROUP BY
  • Spreadsheet basics: formulas, filters and one pivot table
  • Can describe the steps of a funnel in an app you use, such as opening a food-delivery app and placing an order
  • Can describe one analysis you did on sample or real data, and share it where you have permission

Who can apply

Final-year students and graduates of any stream can apply, including B.Tech, BCA, B.Sc, BCom, BBA, MBA, MCA and M.Sc. The role rewards clear questions about product data more than any particular degree, so shortlist on SQL and one analysis the candidate can explain.

How to apply

Apply through this job post by [Apply by]. Shortlisted candidates will hear from us about the next steps.

Other titles for this role

Junior product analyst, Associate product analyst, Product analytics trainee, Growth analyst (fresher), Analyst, product analytics.

Screening questions to add to your job post

  1. Sign-ups fell last week. What do you check first? Look for a check that the drop is real (tracking changes, the date range, duplicate or missing rows) before any explanation, then a split by source, platform, app version or city. Accept any sensible order if the candidate says why.
  2. How would you define retention for a food-delivery app or a learning app? Look for a chosen action that fits the product (an order, a completed lesson), a time window and a clear group of users. Accept a definition based on opening the app if the candidate explains why it fits.
  3. A button on the checkout page was changed and more people tapped it. How would you tell whether the change helped? Look for completed orders or another agreed outcome, not taps alone, compared between randomly assigned groups over the same dates. If everyone saw the change, accept a before-and-after analysis only when the candidate says it cannot by itself establish that the change caused the result and checks other explanations, such as a sale, festival or release. Asking a senior to check the design is sensible.
  4. A manager compares a Diwali sale week with a normal week and says the new onboarding screen worked. What is wrong with that comparison? Look for the sale, seasonality or a changed audience as alternative explanations. A Diwali week and a normal week cannot by themselves isolate the effect of the onboarding change. Accept a suggestion for a concurrent randomised comparison or a clear statement that the result is inconclusive. Rates can account for different group sizes but do not remove these alternative explanations.
  5. A table of events has user_id, event_name and event_time. How would you count users who signed up and then placed an order within seven days? Look for matching sign-up and order events on user_id, keeping orders that occur after sign-up and within seven days, and counting each qualifying user once. The candidate should avoid counting users whose only order preceded sign-up. Accept a plan in words or rough SQL; exact syntax is not the test.
  6. The dashboard counts more ‘order placed’ events than the orders table holds. What could explain it, and how would you check? Look for events that fire twice, retries, test or internal accounts, orders cancelled afterwards or a different definition of an order. Accept a plan to read a sample of raw rows before changing anything.
  7. Describe one analysis you did on real or sample data and the question it answered. Share a link or a file if you can, or describe it if the work is private. Look for a clear question, the candidate’s own steps and a finding that could change a decision. Accept a description or a walkthrough in place of a link.

What to look for when you shortlist

  • A project that starts with a product question and ends with a finding and a next step
  • Written metric definitions that say what counts, the time window and the source table
  • SQL the candidate can explain on sample data, including a join and a group-by, with the result checked against a second source
  • Notes on limits, such as a short period, a small sample, a tracking gap or another possible cause
  • Chart titles that state the message, with labelled axes and the date range visible
  • Questions about your product: who the users are, what a good outcome looks like and how the metric is measured today

Mistakes to avoid in this job description

  • Asking for machine learning or Python by default: keep the must-haves to SQL, a spreadsheet and one BI tool, ask for Python only when the first tasks require it, and use the data scientist template for modelling work.
  • Writing a vague ‘data-driven decisions’ post that names no product or question: say which product the analyst will study, which question comes first, such as why second-week retention fell, and which tool holds the data.
  • Setting a test with no sample data: send a small made-up table of sign-ups and orders in advance, set a time limit, share what you will mark, make it solvable with a spreadsheet or a free SQL tool, keep real company data and your actual backlog out of it, and do not use the answer in your work.
  • Shortlisting on a dashboard that looks good: ask what decision it supports, how each metric is defined and how one count was checked against a second source, because a tidy page can sit on a wrong number.
  • Naming no owner for tracking: say whether the analyst only reads events or also writes tracking requests for engineers, and who tests them, so candidates know where the job ends.

Questions about hiring a product analyst

What should a fresher product analyst know?

SQL for event and user tables, a spreadsheet for cross-checks, one BI tool, and plain ideas of funnels, cohorts, activation and retention. Add the habit of checking a number against a second source and writing a finding in a few lines. Python is optional and machine learning is not needed. Ask to hear one analysis the candidate did, from the question to the finding.

How is a product analyst different from a data analyst, a business analyst or a product manager?

This page assumes an analyst who studies how people use a digital product. A data analyst reports on business data such as sales, operations or marketing. A business analyst agrees requirements with stakeholders and can also map processes. A product manager decides what to build. SQL, spreadsheets and A/B test reading overlap across these roles. A job titled ‘product analyst’ can also mean market research or product-management support, and ‘growth analyst’ posts can add campaign reporting, so list the duties you need.

Should a fresher product analyst know Python, machine learning or a tool like Mixpanel?

Keep Python optional unless the first tasks require it, such as cleaning event data, automating repeated analyses or analysing experiments; leave machine learning out of this fresher template. An event analytics tool such as Mixpanel, Amplitude or Google Analytics is a plus, but the ideas behind it (events, properties, funnels, cohorts) carry across tools, and the team can teach the screens. Name the tools you use in the post.

Can a fresher product analyst work on A/B tests?

Yes, with a senior reviewing the analysis. The fresher checks random assignment, matching dates, agreed metric definitions and source totals, then reports the observed difference and its uncertainty. Ask the senior to review confidence intervals or the experiment tool’s equivalent, and any adverse effects on other agreed metrics. Keep inconclusive results labelled as such. Launch decisions stay with the product manager and senior analyst. Omit these duties if your team runs no experiments.

What should a fresher product analyst work on in the first three months?

Expect SQL practice on your own tables, a dictionary of the team’s metrics, a dashboard to maintain, tracking checks with engineers and a few small questions from product managers. As the fresher demonstrates reliable checks, let them answer a small, clearly defined question and explain each number, with a senior reviewing the note before it informs a decision. Open-ended studies and experiment design stay with a senior.

What project suits a product analytics intern?

Pick one product question with a clear finish, such as where new users drop off between sign-up and first order. Give the intern made-up sample data, or a copy the data owner has approved with personal details removed, plus a mentor, a weekly review and a short presentation at the end. Posting the internship on LineupX is free, with no hidden charges, and you can add screening questions to your post. Tell the intern that any publication of the work needs your approval.

Post your product analyst job free

Paste this job description into a free LineupX job post, add your screening questions and share it with students across 100+ institutions and edtechs. No hidden charges, no limit on jobs.