Build Your Own Analytics
& Debug It Like a Pro

Four Components. Zero Cookies.

The entire system has four pieces, each doing one job brilliantly:

The Tracker (ps.js) — A 1KB script on every page. Uses sendBeacon to fire a non-blocking POST with page path, referrer, screen size, language, and a session ID stored in sessionStorage (not cookies). Returns instantly. Visitors never notice.

The Worker (Cloudflare) — A serverless function at the edge. Receives the beacon, enriches it with geo data (country, city, region) from Cloudflare's network for free, parses the User-Agent for browser/OS/device, and writes to D1. Returns "ok" immediately — the database write happens in the background via ctx.waitUntil().

D1 Database — Cloudflare's SQLite-at-the-edge. A single page_views table stores everything. Free tier handles 100K writes/day — more than enough for most sites.

The Dashboard — A password-protected page on your site at /analytics/. Login hashes your password with SHA-256, sends it as a Bearer token. The Worker validates it. Chart.js renders the data. No analytics data exists in the HTML source — everything is fetched via authenticated API.

Every Dimension. No Third-Party API.

All of this comes free from the browser and Cloudflare's edge network:

1KB That Does Everything

The entire tracking script fits in under 1 kilobyte. Here's what it does:

Two critical details most tutorials miss:

1. Use a Blob, not a string. sendBeacon(url, string) sends with Content-Type text/plain. The server's request.json() may silently fail. Wrapping in new Blob([data], { type: 'application/json' }) ensures correct parsing.

2. sessionStorage, not cookies. The session ID resets when the tab closes. No cookie banners needed. No GDPR headaches. No PII stored.

Your Backend in 200 Lines

The Cloudflare Worker handles three endpoints:

• POST /api/v — Records a page view (non-blocking)
• GET /api/stats — Returns dashboard data (authenticated, cached)
• GET /api/realtime — Active visitors in last 5 minutes

Geo enrichment — free from Cloudflare

Non-blocking writes — return instantly

Batch queries — one round-trip for the entire dashboard

Password-Protected. Data-Rich.

The dashboard lives at /analytics/ on your site. It's a single HTML page with a login screen.

Here is the dashboard with real data — stat cards, engagement metrics, visitors over time, top pages with avg read time and scroll depth:

Scrolling down: cities, device/browser/OS charts, referrers, UTM campaigns, hourly traffic, and timezones:

When you log in, the page hashes your password with SHA-256 in the browser, sends it as a Bearer token, and the Worker compares it against the stored hash. If it matches, you get your data. If not, nothing.

The dashboard shows: visitors over time (line chart), top pages (bar chart), countries with flag emojis, cities, device breakdown (doughnut), browsers, operating systems, referrers, screen resolutions, and languages. Chart.js handles the rendering. A real-time "active now" counter refreshes every 30 seconds.

The page is marked noindex, nofollow so search engines ignore it entirely.

Browser Only. No CLI Required.

Every step can be done from your browser — no terminal, no npm, no wrangler CLI.

• Sign up for Cloudflare

  Free tier. Go to dash.cloudflare.com and create an account.

• Create a Worker via GitHub

  Workers & Pages → Create → Continue with GitHub → select your repo → set root directory to /analytics/worker.

• Create the D1 Database

  D1 → Create → name it. Click into it → Console tab → paste the CREATE TABLE SQL → Execute.

• Generate your password hash

  Open any browser console and run: crypto.subtle.digest('SHA-256', new TextEncoder().encode('your-password')).then(b => console.log(Array.from(new Uint8Array(b)).map(x => x.toString(16).padStart(2,'0')).join('')))

• Set the Secret

  Worker → Settings → Variables and Secrets → Add → type: Secret, name: ADMIN_PASSWORD_HASH, value: your hash.

• Add a Custom Domain

  Worker → Settings → Domains → Add Custom Domain → ps.yourdomain.com. This bypasses ad blockers.

• Add the tracker to all pages

  Add <script defer src="/lib/ps.js"></script> before </body> on every page. Deploy.

Your Debugging Command Center

Chrome DevTools is built into every Chrome and Edge browser. It is the single most powerful debugging tool a web developer has. Here is how to open it and what each panel does.

Three ways to open DevTools

The six panels you need to know

Run Commands. Inspect Everything.

The Console is where you talk to the browser. Open it with F12 → Console tab (or press Esc while in any other panel to open a console drawer at the bottom). Here are the commands you'll use most:

Inspecting the page

Testing API calls directly

When the tracker isn't working, bypass it entirely and test the server:

Generating a SHA-256 hash (for dashboard password)

Useful console methods

See Every Request Your Browser Makes

Open DevTools → Network tab → refresh the page. Every file, image, font, API call, and beacon appears here in chronological order.

Understanding each column

• Name — The file or endpoint requested. Click it to see full details (headers, payload, response).
• Status — 200 = success. 304 = cached. 404 = not found. 500 = server error. (blocked) = ad blocker killed it. CORS error = cross-origin failure.
• Type — document = HTML page. stylesheet = CSS. script = JS. ping = sendBeacon. fetch = fetch() API. preflight = CORS OPTIONS check.
• Initiator — Which file and line number triggered this request. ps.js:39 means line 39 of ps.js.
• Time — Total round-trip time. High values indicate slow servers or large files.

Clicking a request — the detail panels

Click any request in the Network tab to open its detail view with these sub-tabs:

Network tab power features

Real example: ps.js loaded but no outbound request

In this screenshot, notice that ps.js loaded successfully (200) but there is no collect or v request. The tracker script ran but exited silently — this was caused by navigator.doNotTrack being enabled:

Real example: dashboard API calls working

When the dashboard is working correctly, you see the realtime API calls returning 200 with preflight checks passing:

Inspect the Page. Inspect the Storage.

Elements panel: live HTML & CSS

Right-click any element on the page → Inspect. You jump straight to that element in the DOM tree. You can:

• Edit HTML — Double-click any tag or text to edit it live. Changes are temporary (refresh to reset).
• Edit CSS — In the Styles pane on the right, click any value to change it. Add new rules. Toggle properties with checkboxes.
• Check computed styles — Click "Computed" tab to see the final resolved values (after all CSS cascade).
• Find hidden elements — Elements with display:none or visibility:hidden are visible in the DOM tree even though you can't see them on the page.
• Search the DOM — Press Ctrl+F in the Elements panel to search by text, CSS selector, or XPath.

Application panel: storage inspection

DevTools → Application tab (might be behind >> overflow menu). This is where you inspect browser storage:

To verify the tracker session ID exists, go to Application → Session Storage → your domain and look for _ps_sid.

The Elements panel in action

Here is what the Elements panel looks like when inspecting our analytics article. Notice the DOM tree on top showing every section, and the Styles pane below showing computed CSS for the <body> element:

The Elements panel is your X-ray vision into any webpage. Right-click any element on the page → Inspect to jump straight to it in the DOM tree. Change text, toggle CSS properties, and see results instantly.

The Ad Blocker Wall

Here is what it looks like in the Console — a red error that tells you the resource was killed before reaching the server:

And in the Network tab, the request shows as (blocked) with type ping — the ad blocker intercepted the sendBeacon call. Click the request to see the Headers panel showing "Provisional headers" — meaning the request never actually left:

After renaming the endpoint from /collect to /api/v, the ad blocker STILL blocked it — this time matching on the workers.dev domain:

Ad blockers use pattern matching on URLs, domains, and request types. Here is our debugging timeline — four attempts before success:

When Domains Don't Trust Each Other

The CORS handshake

Here is what a CORS error looks like in the Network tab. Notice the preflight (OPTIONS) returned 200, but the actual ping request shows CORS error. The Issues panel at the bottom flags it: "Ensure credentialed requests are not sent to CORS resources with origin wildcards":

And here is the full browser view — the page loaded fine, but the analytics beacon failed silently with a CORS error visible only in DevTools:

Our specific issue: ps.paddyspeaks.com is a subdomain, so cookies for .paddyspeaks.com are sent automatically. This makes it a credentialed request — and credentialed requests cannot use the wildcard * origin.

Reading the Red Text

The Console tab (F12 → Console) shows JavaScript errors. Here is what multiple errors look like stacked together — each one telling a different story:

Read each error from top to bottom. The file and line number on the right (e.g., resume.html:610) is a clickable link — it takes you directly to the problem in the Sources panel. Here are the three errors we hit and what each one teaches:

Uncaught SyntaxError: Unexpected end of input (at resume.html:610)

A script tag inside a template literal

When we injected the tracker using sed before every </body>, it also matched </body> tags inside JavaScript template strings (backtick strings for print/export). The injected <script> tag broke the template literal's syntax.

Fix: After bulk injection, check files with template literals or inline JavaScript. Remove any tracker tags that ended up inside JS strings.

No Error. No Warning. No Data.

The hardest bugs aren't the ones that scream. They're the ones that whisper.

Do Not Track: The invisible guard

The tracker loaded (200 in Network tab). No console errors. But no /api/v request was sent. The data was simply... missing.

The culprit: navigator.doNotTrack === '1'. Our tracker had a guard clause that silently returned if Do Not Track was enabled. Many browsers enable DNT by default. The W3C abandoned the DNT specification years ago. Even privacy-respecting tools like Plausible and Umami ignore it.

sendBeacon Content-Type: The invisible mismatch

Even after fixing DNT, the D1 database was empty. The beacon was being sent (visible in Network tab). The Worker returned "ok". But no rows appeared in the database.

The root cause: sendBeacon(url, string) sends with Content-Type text/plain. The Worker's request.json() silently failed to parse it. Since the DB write was in ctx.waitUntil(), the error was swallowed — and the response was still "ok".

A Systematic Approach

The next time something doesn't work, follow these steps in order:

• Open the Network tab

  Is the request being made? If it's not there, the code didn't fire. Check guards, ad blockers, and script loading.

• Check the status code

  200 = success. (blocked) = ad blocker. CORS error = missing headers. 500 = server crash. 401 = auth failure.

• Open the Console tab

  Red text = errors. Read the message and the file:line reference. Click to jump to the source.

• Test the API directly

  Run fetch() in the Console with the correct headers. This bypasses the tracker and tests the server directly.

• Read the guard clauses

  Open the source code (Sources tab). Look for early return statements — DNT checks, prerender guards, bot filters.

• Check the server

  Look at server logs, database console, or Worker metrics. The client may say "ok" but the server may be failing silently.

Quick Reference

You now own your analytics — every byte of visitor data sits in your database, viewed through your dashboard, protected by your password. No Google. No cookies. No consent banners.

And the next time something breaks — because it will — you know exactly where to look.

Read more at paddyspeaks.com