Analytics for Startups: What to Measure in Year One (and What to Ignore)
Most early-stage founders spend time looking at metrics that feel important but don't drive decisions. Here's a clear framework for what your analytics need to answer — and the fastest way to set it up correctly.
The vanity metrics trap
There's a version of analytics that feels productive but isn't. You open a dashboard, see some numbers, feel vaguely informed, and close it. The numbers went up this week? Good. Down? Concerning. But you don't know why, and you don't change anything as a result.
This happens because most founders start with the wrong question. They set up analytics to "track traffic" — a passive, accumulative thing. What you actually need is analytics that answers specific questions about whether your acquisition, activation, and retention are working. Those are three fundamentally different things, and only one of them is traffic.
The five questions year-one analytics need to answer
Before you install anything, write down these questions. Your analytics setup should make all five answerable within two minutes of opening the dashboard.
1. Where is my traffic coming from?
This is the acquisition question. Which channels are actually sending visitors — organic search, direct, referrals from specific sites, social, email? You need this broken down so you know where to double down and where to stop spending time.
The trap: looking at total sessions without the referrer breakdown. "5,000 visitors this month" is not useful. "3,200 from Hacker News, 800 from organic search, 600 direct" tells you something actionable.
2. Which pages do people actually read?
Not just which pages they land on — which ones they spend time on. A page with 2,000 visits and 8 seconds average active time is performing worse than a page with 400 visits and 3 minutes average time. The former is a bounce; the latter is someone reading your content.
This distinction matters enormously for founders who write content to drive organic acquisition. The page with the most traffic isn't necessarily the one converting readers into signups.
3. What does the path to signup look like?
Which pages are visitors landing on before they create an account? If 60% of your signups come from your pricing page and 5% from your homepage, that's not a coincidence — it's a funnel insight. You should be testing your pricing page copy obsessively and worrying less about your hero section.
4. Are the numbers real?
This one sounds obvious but almost no one actually verifies it. Your analytics figures are only useful if they're accurate. If 30–40% of your audience uses an ad blocker — common for developer, technical, or privacy-conscious audiences — and your tool is blocked by default, your conversion rates, bounce rates, and funnel data are all systematically wrong.
A 3% conversion rate calculated from 60% of real traffic is not a 3% conversion rate. It might be 2%, or 5% — you don't know, because the denominator is wrong. This is a silent problem: your dashboard shows no error and the numbers look plausible.
5. Is there any traction this week?
In the early stage, you need week-over-week signal, not monthly trends. Monthly smooths out too much. Something happened two weeks ago — a tweet, a post, a link from a newsletter — and you need to see the spike and trace it back to the source. If you're reviewing analytics monthly, you've lost that signal by the time you look.
Why most founders start with the wrong tool
The default choice is Google Analytics, and it's understandable — it's free, it's familiar from previous jobs, and "everyone uses it." But for a European-market startup, or any startup with a technical or privacy-aware audience, it creates two problems that don't get better with time.
The consent overhead. GA4 sets a persistent tracking cookie, which under GDPR requires a consent banner before it fires. This means your data collection is gated behind a UI that a meaningful percentage of users will dismiss, ignore, or explicitly reject. Typical acceptance rates land between 40–75% depending on banner design. You're starting your analytics journey with a structural data quality problem baked in — and adding engineering and legal overhead to manage a banner on a product that doesn't need it.
The block rate. GA4's script is on every major ad-blocking list. Brave blocks it by default. uBlock Origin blocks it. Firefox's Enhanced Tracking Protection blocks it in Strict mode. For developer tools, dev blogs, fintech products, and anything targeting a technical audience, ad blocker adoption frequently exceeds 40%. Every blocked visit is invisible: no error in your dashboard, just a missing row.
Neither of these is a theoretical problem. They compound: a user who blocks ad trackers is also more likely to reject a consent banner. That user — often your most technically sophisticated prospect — is simply absent from your data.
The consequence: the metrics you're using to make product and marketing decisions are based on a biased sample of your real audience. The users who are invisible in your analytics aren't random — they're systematically different from the users you can see.
What an early-stage setup actually looks like
For a pre-revenue or early-revenue startup, your analytics needs are simple: you need accurate pageview and session data, reliable referrer attribution, and active time on page. You do not need heatmaps, cohort analysis, multi-touch attribution, or custom event schemas — not yet. Those are problems for after you have enough traffic to make them meaningful.
The criteria for a year-one analytics tool:
- Works through ad blockers — if your tool is on the EasyPrivacy or EasyList block lists, you're not measuring your full audience
- No consent banner required — one less thing to build, one less thing to maintain, zero data loss from consent dropoff
- Referrer tracking — which channels, which specific pages or posts sent you traffic
- Active time on page — wall-clock session duration (GA4's approach) is misleading; you want a timer that pauses when the tab is backgrounded
- Fast setup — one script tag, no configuration, no tag manager, no data layer
Setting up correctly in under 10 minutes
The actual installation is one line of HTML in your <head>:
<script src="https://logly.uk/p.js?s=YOUR-SITE-ID"
data-site="YOUR-SITE-ID" async></script>
That's it. No configuration file. No data layer. No tag manager to configure. The script is under 1 KB, loads asynchronously, and has zero impact on your Lighthouse score or Core Web Vitals. It doesn't set cookies, so there's no consent banner, no legal exposure, and no data loss from users who would have rejected consent.
The dashboard gives you what you need for the five questions above: top pages, referrers, countries, devices, and active time on page — with a comparison to the previous period so you can see the week-over-week signal immediately.
The weekly 10-minute review
Analytics that don't drive decisions are noise. Build a simple weekly habit: open the dashboard on Monday morning, look at last week vs the week before, and ask three questions.
- What drove the spike or drop? Look at referrers first. If traffic was up 40%, where did it come from? If it was flat, are your main acquisition channels holding?
- Which pages are working? Sort by active time, not just pageviews. A page people actually read is worth more than a page they bounce from. If a secondary post is outperforming your main landing page in engagement, there's signal there.
- Is the signup path intact? If you have event tracking on your signup button or form submission, check whether it moved. A drop in that event that isn't explained by a traffic drop is a conversion problem — something broke or changed in the flow.
Three questions. Ten minutes. Write down one thing you learned and one thing you're going to test or change because of it. That's the whole protocol.
When to add more
Expand your analytics stack when you've exhausted what basic traffic and referrer data can tell you — not before. The natural progression:
- Custom events — once you have consistent traffic, add event tracking to your key conversion actions (signup button, pricing page CTA, key feature usage). This is when you start building a real funnel view.
- Segment by channel — when you're running multiple acquisition bets simultaneously and need to understand which one is converting, not just which one is sending traffic.
- Retention metrics — when you have enough users to make cohort data meaningful. Before you have 200+ active users, retention numbers are too noisy to act on.
The common mistake is adding instrumentation before you have enough volume to interpret it. Adding 30 custom events to a site with 500 monthly visitors produces data you'll stare at and not learn from. The noise-to-signal ratio is too high. Start with the basics, get them right, and layer in complexity as the traffic justifies it.
One thing most founders don't do
Compare your analytics numbers to your server logs or payment processor data. If your analytics says 5,000 sessions and your payment processor shows 50 completed checkouts, your conversion rate is 1%. But if your server logs show 7,500 requests to the checkout page and only 5,000 made it into analytics — because 2,500 were from users with ad blockers — your actual conversion rate might be closer to 0.67%. That's not the same business.
Running a quick sanity check between your analytics data and a ground-truth source (server logs, payment counts, email signups from your CRM) is the fastest way to understand how much your current tool is underreporting. Most founders who do this check are surprised by the gap.
Analytics that works from day one
Under 1 KB, no cookie banner, no ad blocker blindspot. Free up to 10,000 pageviews/month — enough to cover most early-stage products through their first year.
Get started free →