In September 2018, I wrote the first version of an article about how to become a web analyst. I recommended building your own test website, using Google Analytics, Google Tag Manager, working with spreadsheets, learning step by step, gaining experience in online marketing, staying technically curious and being willing to help others.
Eight years later, I still stand by most of those principles. But the field and the way we can learn it has changed. Today we work with Google Analytics 4 (GA4), consent, data warehouses, automation and artificial intelligence. Analysts encounter code, APIs and data quality more often.
That sounds more complicated than it did in 2018. At the same time, it has never been easier to get started. AI can explain documentation, help you read JavaScript, suggest SQL, create a test website or prepare the first version of a validation script.
You do not need to know everything straight away. You will gain most of your knowledge gradually while solving specific problems. Piece by piece.
An AI-boosted analyst is not someone who merely produces more outputs faster. With AI, they learn faster, document better, test more and spot errors sooner. But they are still accountable for the result.
What I would not change after eight years
Tools change. The fundamental principles remain:
- Build your own test website or application.
- Follow the path from the question, through data generation, to a decision.
- Do not merely click your way to a report. Understand what the numbers mean for a particular business.
- Learn to read documentation and understand the technical basics of a website.
- Help others. Other people’s problems will often teach you more than another general course.
- Do not bend the numbers to suit a stakeholder’s wishes.
- Admit when you do not know something. It is safer than guessing convincingly.
It is still important to understand the journey from data generation, through processing, to interpretation. AI can help you at every step, but it should not completely hide any of them.
Do not overwhelm yourself: you do not need to know everything immediately
The list of topics in web analytics now seems endless: GA4, GTM, consent, SQL, data warehouses, statistics, experiments, JavaScript, cloud, AI, automation, server-side measurement and first-party data. When you view it as a single package, it is easy to feel that the field is impossible to enter.
It is not. You simply do not learn it all at once.
Start with a few fundamentals:
- What question are we trying to answer?
- What data do we actually need to answer it?
- How will the data be generated?
- How will we know that it is correct?
- What can and cannot we claim based on it?
- What next step will we recommend?
Other knowledge will gradually build on this foundation. In your first month, you do not need to understand the data architecture of a large company. It is enough to measure a form submission correctly, verify the event in the browser and explain what the number means.
Advanced topics may be interesting, but they are not an entrance exam. Server-side GTM, server-side measurement and extensive work with first-party data are useful in specific situations. Until you have mastered the fundamentals, however, you do not need them.
First, master simple client-side measurement, validation, interpretation and communication. Learn more advanced architecture when it solves a real problem, not because it sounds modern.
What I would recommend differently today
Build your own lab
In 2018, having your own website with tracking code was enough. Today, I would recommend a small environment in which you can modify the website, send events to GA4, inspect the data layer, create reports, write scripts, keep changes under version control and safely break things.
It can be a static website, WordPress, a small mock online store or an application created with the help of AI. It does not need to look good. It needs to be yours and allow you to experiment.
If you are not ready to build your own website yet, start with the GA4 demo account. However, your own project will later be very useful for understanding implementation and troubleshooting.
Start with the question, not the tool
Choose a simple problem: where people come from, how many of them submit the form, where they abandon a purchase or how you can tell that tracking has stopped working.
Only then choose the data and tools. Follow this sequence:
- What decision do we want to make?
- What information do we need to make it?
- What data could support it?
- How will we obtain and validate that data?
- How will we explain the result to the person making the decision?
I still use the same principle today: understand the problem and its context first, then design the solution.
Do not be afraid of the technical side, but take it step by step
You do not need to become a developer. But learn to open Chrome DevTools, read basic HTML, find an event in the dataLayer, inspect a network request and recognise an error in the Console.
AI can explain code line by line and prepare a small example. Change it, run it and verify it yourself. You do not need to understand everything on the first day. What matters is gradually improving your ability to recognise when an output behaves differently from what you expected.
There is a place for junior analysts
But they need an environment with regular review, clear definitions, a test environment, limited production permissions, documentation and the ability to admit a mistake without hiding it.
AI shortens the path to the first useful result. It does not automatically shorten the path to professional judgement. A beginner with AI and full production access does not become a senior. They can simply create both good and bad changes faster.
Advice for junior analysts: if you do not know, ask
At the beginning, you will not have enough experience for every situation. That is not a failure; it is the nature of a junior role.
A junior does not need to know every answer. They need to recognise when they do not know, ask for help, verify the result and record what they learned.
When you get stuck, ask questions. At first, feel free to ask AI before anyone else. It will not judge you for a basic question, and you can ask it to start completely from scratch. The worst question is usually the one you do not ask, replacing it with an unverified assumption instead.
AI is a good first consultant, not the final authority. It can help you name the problem, explain a concept, translate an error message, suggest possible causes and prepare a testing procedure.
For complex tasks, use the most capable model you can reasonably access. A faster, cheaper model can handle routine work. A data model, complex SQL query, production change or client-facing interpretation deserves more context and more rigorous review. For an important problem, you can compare two models. Their agreement is not proof of correctness.
When an answer affects production, money, personal data, security or a client decision, ask a more experienced person as well. AI knows general best practices. A colleague may know the history of the specific system and why the general solution does not work there.
Console is your friend. Version control is your safety net
Do not hide inside the graphical interface. Look at the Console and Network panels, and inspect requests, responses and errors. The console may not give you the complete solution, but it will reveal the first concrete clue.
Learn the basics of working in a terminal. Codex or Claude Code can act as a pair programmer that explores files, explains code, proposes changes and runs tests.
Store important changes in Git. This gives you a change history, the ability to compare versions, a basis for review and a way back. An AI agent without version control, tests and diff review can change more in a few minutes than you can safely inspect.
Do not be afraid to say, “I don’t know”, “I’ll verify it” or “I can’t do that yet, but I’ll learn”. It is far worse to hide uncertainty behind a confident answer.
Your first practical project
Instead of randomly clicking around tools, complete one small project from beginning to end.
1. Create a simple website
A home page, a few articles or products, a form, a thank-you page, an external link and a downloadable file are enough. AI can help you create the first version. Store it in Git.
2. Write a measurement plan
Do not start with a list of every possible event. Describe the website’s objective, its primary user, the key steps, the required events, parameters, the definition of success and prohibited data.
| Area | Example |
|---|---|
| Objective | Generate qualified enquiries |
| Key steps | View a service page, open the contact form, submit the form |
| Events | view_service, contact_start, generate_lead |
| Prohibited data | Email address, phone number, message content and other personal data |
| Validation | Test scenario and expected result |
The measurement plan is more important than the number of tags. It creates a shared language between the analyst, developer, marketing team and AI.
3. Implement basic measurement
Try both deployment through GTM and a simple direct implementation in code. There is no rule that one approach is always right. What matters is who owns the change, how it is approved, tested and deployed, and how it is rolled back if necessary. I write more about this in Do We Still Need Google Tag Manager in the Age of AI?.
4. Validate the implementation from several angles
Seeing a number in a report is not enough. Check:
- tags in Tag Assistant or Preview mode,
- events and parameters in GA4 DebugView,
- the
dataLayer, network requests and console errors, - duplicates, missing values, and both the mobile and desktop versions,
- behaviour before and after consent, including Consent Mode when you use it,
- integration with the backend or business system, when one exists.
Write down the expected result before each test. “Something appeared in GA4” is not an adequate definition of success.
5. Create a simple report
Start with a table and a few questions: what happened, compared with what, what could explain the change, what do we not yet know and what next step do we recommend?
A chart is not the final outcome. The outcome is a better decision or an honest statement that the available data does not yet support a decision.
6. Break something deliberately
Send an event twice, change a parameter name, remove the data layer or break the form tracking. Then find the error and revert the change.
You will learn more from this than from following a tutorial perfectly. Real-world analytics is largely about working with incomplete information, changes and errors.
A minimum toolset for 2026
A beginner does not need twenty paid platforms. A basic set is enough:
- GA4 for the event model and basic reports.
- GTM or a direct implementation for data collection.
- Chrome DevTools for the network, console, DOM and storage.
- Google Sheets or Microsoft Excel for basic data work.
- Data Studio for simple reports and dashboards.
- SQL and BigQuery as the next step, for example through the GA4 export to BigQuery.
- Git and, when needed, GitHub or GitLab for version control and review.
- One high-quality AI service.
- Codex, Claude Code or another environment for working with code and AI.
- A few Markdown files for documentation.
Tools are not collectibles. Choose a small set and learn to use it in depth. And remember: GA4 is not web analytics. It is just one tool.
Pay for a high-quality AI service and explore its limits
Today, I would recommend that beginners pay for a high-quality AI service for at least a few months, such as ChatGPT, Claude (not Gemini). Not because a paid model is always right, but because you will usually have more room to learn, work with longer context and try more advanced features.
Use AI intensively enough to understand:
- where it saves you significant time,
- when it needs precise context,
- when it makes up missing information,
- how it works with code, spreadsheets and documentation,
- what it cannot verify,
- when it starts changing parts of the solution that were already correct,
- when completing the task manually is faster.
Keep up with new developments and try them, but start on your own safe project. What was right eight years ago may not be right today. A year from now, the same may be true of the approach we recommend today.
You can use AI as:
- a teacher that explains a concept, code or network request and prepares an exercise,
- an analytical partner that suggests hypotheses, segmentation and alternative explanations,
- a pair programmer that prepares SQL, JavaScript, a Python script, a test or documentation,
- a critical reviewer that looks for weaknesses in a conclusion, definitions and the data used,
- a project memory that you feed verified, maintained context.
For that last role, maintain files such as README.md, MEASUREMENT_PLAN.md, DATA_DICTIONARY.md, DECISIONS.md, TESTS.md, INCIDENTS.md and AGENTS.md or CLAUDE.md.
When developing with AI, proceed in small steps. First let it explore the current state and describe the plan and risks. Then change one thing at a time, review the changes, run tests and deploy to a safe environment before production. For a production change, have monitoring and a rollback plan ready.
This is not blind vibe coding. It is AI-assisted work in which a human has the final say. The ability to create a change quickly is not the same as the ability to operate it safely in production.
Do not feed personal data, access tokens, trade secrets or confidential client data into an AI service without careful thought. First verify your organisation’s rules and how the service handles data.
You are accountable for AI output
Once you send AI-generated output to a client, include it in a report or deploy it to production, it is YOUR output. When it is wrong, an “AI error” is not an acceptable excuse. It is YOUR professional error.
AI is a tool that you selected and whose output you accepted. The level of review must match the risk.
| Risk | Example | Proportionate review |
|---|---|---|
| Low | An explanation of a concept while learning | Documentation and hands-on verification |
| Medium | SQL for an internal analysis | Logic review and a test on a sample |
| High | Numbers for a client or leadership | A verified definition, reproducible calculation and independent review |
| Very high | Production, personal data or security | Limited permissions, review, tests, monitoring and rollback |
I describe the same principle of accountability in my Code of Ethics.
Admit mistakes and turn them into a better system
Do not hide a mistake. Tell the people it affects, describe the impact, fix it and add a control that reduces the risk of recurrence. Where rules and confidentiality allow, publish an anonymised account of what you learned.
People often value an honest admission and good remediation more than a pretence of infallibility. This does not apply to intentional misconduct, ignoring a known risk or negligence.
Always share the lesson internally within the project; you may also share it publicly. Describe the problem, the cause, the fix and the new control. Always anonymise the client and the data, however, and do not publish anything that breaches confidentiality or could harm users or the security of the system. The goal is not to turn someone else’s incident into content, but to demonstrate a better approach.
A single mistake can become a learning experience. Repeating the same mistake is usually a process failure.
Record every significant mistake:
## Incident date and title
Context: What changed, and why?
Symptom: How did we discover the problem?
Impact: Which data, periods and decisions could it have affected?
Cause: Why did the error actually occur?
Fix: What did we do immediately?
Prevention: What test, control or rule will we add?
Context for AI: What should be added to the project documentation from now on?The record is not a punishment. It is external memory for you, your team and AI.
A good system for handling errors has four layers:
- Prevention: clear definitions, small changes, limited permissions, review and a checklist.
- Detection: automated tests, freshness checks, anomaly monitoring and comparison with the backend.
- Response: a clearly identified owner, a description of the impact, the ability to stop or roll back the change, and transparent communication.
- Learning: an update to a test, documentation or process so that the same error does not recur.
Build small error-checking tools
Start with a tool that solves one recurring problem: checking required parameters, duplicate events, UTM parameters, data freshness, conversion drops or discrepancies between analytics and the backend.
AI can help you create the first version. Your task is to understand what the tool does, what its limitations are and how you will know when it has failed.
The best first automation is often not another report. It is a check that warns you not to trust the data in the report.
What to learn and where to gain experience
The shared foundation consists of business and product knowledge, measurement design, implementation and debugging, working with data, interpretation, communication, privacy and the safe use of AI. You do not need to master them all. You need to gradually understand how they relate to one another.
Later, you can choose a specialisation:
- measurement engineering and data-collection quality,
- marketing or digital analytics,
- product analytics and experimentation,
- BI and analytics engineering,
- data quality and governance.
You do not need to decide immediately. First, work through the entire flow from the question to the recommendation.
You can gain your first experience at an agency, on an internal analytics team, at a product company, in an e-commerce business, on a development team, on a non-profit project or on your own website. The environment matters more than the employer’s name. When choosing a role, ask:
- Who will review my work regularly?
- Will I see the entire process from the initial request to its impact?
- How are changes tested and rolled back?
- Is there a data dictionary and documentation?
- How does the team handle incidents?
- Does the team use AI responsibly, or does it merely push for speed?
For a junior, a mentor and high-quality feedback are more valuable than a long list of modern tools in a job posting.
A portfolio is more valuable than a pile of certificates. Prepare two or three small case studies:
- a measurement project covering design, implementation and validation,
- an analysis that leads to a decision and acknowledges uncertainty,
- a simple data-quality tool.
For the first, show the measurement plan, test scenarios, evidence of validation and known limitations. For the second, describe the original question, metric definitions, alternative explanations and the recommended next test. For the tool, explain what problem it solves, how it has been tested and when it may fail.
Feel free to say where AI helped. What matters more is explaining what you verified, what you changed and what you are accountable for.
Learn in a cycle: ask a question, ask AI for a map of the problem, try a solution, inspect the console and the data, read the official documentation, run a test, ask for review and record the lesson.
Assess sources roughly in this order: a reproducible test and the system’s actual behaviour, official documentation, primary data, reputable experts, community discussion, and only then an unverified AI answer or a confident post without evidence. AI can generate convincing, authoritative-sounding errors at very low cost.
Use Google Skillshop for foundational learning, but no course can replace your own implementation. Read English-language sources and meet people, for example at MeasureCamp Czechia. When you explain a solution to someone else, you quickly discover whether you truly understand it.
When do you become a web analyst?
Not after installing GA4 or earning one certificate. It happens gradually, when you can understand a problem, turn it into questions, design and validate measurement, recognise the limitations of the data, explain the result and recommend the next step. The role also includes responsibility for the quality of the output and the ability, after a mistake, to fix not only the number but also the process that allowed the mistake to happen.
At the beginning, you do not need to handle all these parts independently. You need to know that they exist and gradually gain hands-on experience with them through real tasks.
A practical plan for your first 90 days
| Period | Focus | Output |
|---|---|---|
| Weeks 1 to 2 | Test website, GA4, Console and Network | A working website and a basic README.md |
| Weeks 3 to 4 | Measurement plan, events and validation | A data dictionary and test log |
| Weeks 5 to 6 | Spreadsheet, report and hypotheses | A short analytics case study |
| Weeks 7 to 8 | SQL fundamentals and working with less-processed data | Reproducible queries with comments |
| Weeks 9 to 10 | A small validation script, tests and rollback | A data-quality tool and your first incident record |
| Weeks 11 to 12 | Portfolio, feedback and choice of direction | Two case studies and the next learning plan |
You can complete your first useful project in a few weeks. In a few months, you can become a productive junior analyst in a well-led team. Independent judgement develops gradually through solving real problems.
Frequently asked questions
Do I need to know how to code?
Not for your first report. For long-term growth, I would not avoid coding. It is enough to gradually learn how to read, modify, run and test code, and how to revert a change.
Do I need expensive analytics tools?
No. A free or inexpensive toolset is enough at the beginning. One high-quality AI service, a good course, a conference or a mentor’s time may be more valuable than several overlapping platforms.
Do I need a university degree or advanced mathematics?
Not as an entry requirement. You need logical reasoning, the ability to work with percentages, ratios and uncertainty, and over time a basic grasp of statistics.
Will AI replace analysts?
AI will accelerate or take over many individual tasks. This raises the bar for someone who merely translates requirements into tool settings. We still need people who define the problem, verify the data, assess uncertainty, protect users and take responsibility for the recommendation.
Conclusion: step by step
Web analytics is broader in 2026 than it was eight years ago. That does not mean you need to know the entire field before you begin.
Start with a small website, a simple question and basic measurement. Ask AI questions, use more capable models for important tasks, inspect the Console, store changes in Git and ask a human for help when the risk is high.
Do not be afraid to say, “I don’t know”. Do not be afraid to admit a mistake, fix it and record the lesson. Be more afraid of an error that nobody monitors, a conclusion that nobody validates and the same problem recurring because the process never changed.
A good analyst is not someone who never makes a mistake. It is someone who can detect it, admit it, fix it and turn it into a better system.
And a good AI-boosted analyst does this faster, more consistently and with full accountability for everything they pass on.