DEV Community: Om Yaduvanshi

i open my analytics once a day. for about thirty seconds.

Om Yaduvanshi — Tue, 27 Oct 2026 04:56:59 +0000

most analytics dashboards want you to live inside them. tabs, segments, a report builder that takes longer than the work it is supposed to measure.

i open mine once a day. for about thirty seconds.

i'm om yaduvanshi, 18, an applied ai developer. i built cloudline, a cookieless analytics tool. day 32 now, two days past launch, and the check has settled into a shape.

what i look at first

the visitors over time chart, on one screen. did yesterday move, and in which direction. i do not need a reason yet. i need to know whether there is a reason to look further.

then top pages. which page got read. then traffic sources. search, social, newsletters, ai assistants, grouped. a source showing up that was not there yesterday is a thread to pull.

the second screen, only if the first one earns it

if a page moved, i check how far people got through it. scroll depth, in quarters. i check engaged time next to it. a page with a lot of visits and almost no engaged time is a headline problem, most of the time.

if a button matters on that page, i check its clicks. cloudline stores the label you chose for the button. nothing about the person who pressed it.

what i never open

i do not build a segment before breakfast. i do not compare seven date ranges. the dashboard is there to tell me what changed, and then get out of the way.

a pageview stores page, referrer, screen size, time. nothing else. no cookies. no ip addresses. nothing stored on a visitor's device. that is why the check stays short. there is nothing stored about any individual visitor to dig through.

the point of the check

open it, see what changed, get back to building. that line is on the site, and it is the whole product idea, as far as i am concerned.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

your funnel is two pages and one button

Om Yaduvanshi — Mon, 26 Oct 2026 04:15:49 +0000

i used to think a funnel needed a whole setup. forms, events, a dashboard i had to configure before i could read anything.

it turns out a funnel is two pages and one button. the page people land on, the page they go to next, and the button they press or skip.

i'm om yaduvanshi, 18, an applied ai developer. i built cloudline, a cookieless analytics tool. yesterday was launch day. today is day 31, and this is the first thing i am watching now that anyone can install it.

what a funnel is when there is no cookie

a pageview stores four things. page, referrer, screen size, time. nothing else.

a button click stores the label you chose for it. nothing about the person who pressed it.

cloudline turns those pageviews and clicks into a funnel. you see where people drop off. there is nothing to configure first.

how i read a drop-off

if people read the first page and never reach the second one, the first page is the problem. the headline, the length, the thing it promises and does not deliver.

if people reach the second page and never press the button, the button is the problem. the label, the placement, the ask itself.

that is the whole read. two places where people leave, and each one points at a different fix.

what it never needs

no cookies. no ip addresses. nothing stored on a visitor's device. no user-agent storage, no fingerprinting.

a click is tracked when you add a data attribute to the button, or call cloudline dot track with a label. only that label is stored. the rest of the page stays out of it.

the morning after launch

launch day is loud. the morning after is quiet, and quiet is where you learn whether anything actually works.

i am not watching a number go up. i am watching where people stop. the page they leave from tells me more than any total ever will.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

cloudline is live. analytics without cookies.

Om Yaduvanshi — Sun, 25 Oct 2026 04:13:25 +0000

29 days ago i started writing about a tool i was building. today you can install it.

i'm om yaduvanshi, 18, an applied ai developer. i built cloudline, a cookieless analytics tool. this is day 30 of 90, and it's launch day.

what ships today

one script tag, under 2kb. no cookie banner, because there is nothing to consent to.

a pageview stores four things: page, referrer, screen size, time. nothing else. top pages and traffic sources, with every ai chatbot grouped into one source. engaged time, scroll depth at 25, 50, 75 and 100 percent. button clicks per page. funnels with nothing to configure. live visitors on one screen. up to 50 sites in one dashboard.

install takes under a minute. removing it takes one deleted line.

what it never does

no cookies. no ip addresses. nothing stored on a visitor's device. no user-agent storage, no fingerprinting. device type comes from screen width and nothing else.

when cloudline can't collect something, the dashboard shows an error message instead of a made-up number. same rule as the demo badge and the labelled roadmap: if it isn't there, you see that it isn't there.

what's not shipping

revenue attribution is coming soon and stays coming soon. countries, operating systems and browsers, core web vitals, weekly email reports — all on the roadmap, none of them live. i'd rather ship a short honest list than a long invented one.

30 days later

i wrote about this thing for 29 days before asking anyone to install it. the ad blockers block it, the troubleshooting page lists every way it can fail, and the demo wears its sample-data badge in public.

that was the whole strategy. be honest about the missing parts and people stop worrying about the hidden ones.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

my cookieless analytics gets blocked by ad blockers. that's the honest version.

Om Yaduvanshi — Sat, 24 Oct 2026 04:15:05 +0000

ad blockers block my tracker.

not the creepy one. mine. the one that stores no cookies and no ips.

i'm om yaduvanshi, 18, an applied ai developer. i build cloudline, a cookieless analytics tool. day 29 of 90, building in public. it launches tomorrow.

the page that lists my enemies

every tracker needs a troubleshooting page. mine lists four ways it can fail: your content security policy can refuse the script, an ad blocker can eat the request, localhost events get refused in production, and the domain can just not match.

i wrote all four down instead of pretending they don't happen. a visitor with a blocker shows up as a visitor who never loaded the script. i won't know they visited. that's the price.

why i don't fight back

the fix exists. i could rotate domains, disguise the request, do the cat-and-mouse thing the creepy tools do every day.

every trick that would beat a blocker is a trick i refuse to use. so the script stays dumb. one tag, under 2kb, from one domain. if your blocker takes it down, it takes it down.

the honest part of the dashboard

what i can do is be honest about what's missing. when cloudline can't collect something, the dashboard shows an error message instead of a made-up number. no silent zeros pretending to be real data.

same instinct as the demo badge and the labelled roadmap. if the number isn't there, you should see that it isn't there.

one day left

launch day is tomorrow. day 30 of 90. the thing i'm most sure about after 29 days: people don't punish you for the missing parts. they punish you for the hidden ones.

day 29 of 90. see you tomorrow.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

i count clicks without knowing who clicked

Om Yaduvanshi — Fri, 23 Oct 2026 04:12:15 +0000

i want to know which button people click. i don't want to know who clicked it.

most analytics tools treat those as the same question. they're not.

i'm om yaduvanshi, 18, an applied ai developer. i build cloudline, a cookieless analytics tool. day 28 of 90, building in public.

how click tracking usually works

open any analytics tool's click feature. it's usually a session replay, or a heatmap of real cursors on your actual page.

those need to follow one person around your site. that takes an identity: a cookie, a session id, something that says "this click and that scroll belong to the same visitor". the click count you see is built on top of that identity.

how cloudline does it

you put data-cloudline-track="signup" on a button. or you call Cloudline.track('click', {label}) from your own code.

the label you chose gets stored. the page gets stored. the count goes up. nothing else.

no cookies, no ip addresses, no user agents, no session ids. a click is a number attached to a page. no trail, no person.

what i gave up

i can't tell you if the same person clicked twice. i can't tie a click to the visitor who scrolled to 100% and then left. there is no heatmap of actual cursors, because there are no cursors to record.

that's the trade, and i'd rather name it than hide it.

why this is the shape i want

the whole product works like this. a pageview stores four things: page, referrer, screen size, time. that's the entire row. clicks fit the same shape: label, page, count.

funnels are built from these counts. pageviews and clicks in order, showing where people drop off. nothing in them knows who anyone is.

the part that changed how i read

this changed how i read other tools' privacy pages. "we don't track individuals" next to a feature called session replay. a replay needs a session. a session is an identity wearing a mask.

i'm not naming anyone. but if a tool needs to recognise you to count you, the count is the smaller feature and the recognition is the bigger one.

two days to launch

day 30 of this plan was always launch day. it's two days away now. the click tracking you just read about is the kind of thing launching with it: small, named, and honest about what it doesn't do.

day 28 of 90. still building.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

i track every site i run from one dashboard

Om Yaduvanshi — Thu, 22 Oct 2026 04:14:29 +0000

i run more than one website. every analytics tool i tried made me log in somewhere else for each one, or gave me one dashboard per property with no overview.

i'm om yaduvanshi, 18, an applied ai developer. i build cloudline, a cookieless analytics tool. day 27 of 90, building in public.

why one dashboard

if you have one site, this feature is invisible. if you have five, it's the whole product.

i keep a few projects alive. stores, side pages, landing pages for this campaign. checking them used to mean clicking between properties and losing the thread of what actually mattered. nobody checks analytics they have to hunt for.

how it works

cloudline lets you add up to 50 sites under one account. same login. one dashboard for every site you run.

50 is a ceiling, not a target. the point is that adding a new site is a one-line install, not a new decision. one script tag, data-site-id, done. deleting the line removes it.

the part i dogfood

my own sites run on it. that's how i notice what actually gets checked and what doesn't. real traffic finds your weak spots faster than sample data. (i wrote about labelled demo data last time. this is the other side of that.)

the honest part

the dashboard still doesn't show countries. or operating systems. or core web vitals. the roadmap lists them, they aren't shipped, and cloudline doesn't pretend otherwise.

what i'd like to know

if you run more than one site: do you actually check all of them?

day 27 of 90. still building.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

my demo dashboard is full of fake numbers. they're all labelled.

Om Yaduvanshi — Wed, 21 Oct 2026 04:20:00 +0000

my demo dashboard is full of fake numbers.

nothing on it is real. not a single number. and every one of them is labelled.

i'm om yaduvanshi, 18, an applied ai developer. i build cloudline, a cookieless analytics tool. day 26 of 90, building in public.

the demo problem

every saas product has a demo. almost every demo is fake. most demos never say so. you look at a dashboard full of beautiful made-up numbers and walk away with expectations the real product can never meet.

some products don't fake the demo. they fake the real thing. a chart shows you an estimate and never tells you it's guessing. i've been thinking about this because i had to build a demo this month.

what i actually did

the cloudline demo lives at studio.cloudline.demo. it wears a "demo" badge on every screen. every preview says "preview uses sample data". your own dashboard never shows sample data. your sites only show real visits.

and when something breaks, cloudline shows an error message instead of a wrong number. i wrote about that one already. it's the same instinct.

the lesson

labelling the fake numbers turned out to be a feature. it forced me to be careful about what the real dashboard promises too. once you've drawn the line between made-up and real in one place, you can't blur it anywhere else.

the honest part

the demo can't tell you what your traffic will look like. it's orientation, not a promise. the label doesn't make the numbers true. it tells you they aren't.

the question i keep coming back to

when did you last see a demo that told you the numbers were made up?

day 26 of 90. still building.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

my analytics deletes your data every night. on purpose

Om Yaduvanshi — Tue, 20 Oct 2026 04:17:56 +0000

my analytics keeps your data for about 13 months. then it deletes it. every night, on a schedule, whether i remember to or not.

the pageview is small on purpose. page, referrer, screen size, time. four things, nothing else. no cookies, no ip addresses, no user agents, no fingerprints. but small data still piles up. four fields times a million pageviews is a database full of other people's browsing history, and "we only stored a little" stops being a defense when you store it forever.

so cloudline deletes it. about 13 months of history, then the nightly job takes the oldest day out. 13 months is long enough for year-over-year comparisons and short enough that i'm not holding data from a version of your site that doesn't exist anymore.

deleting a site is even simpler. delete the site, the data goes with it. immediately. not queued, not anonymized later. gone.

i'm om yaduvanshi, 18, an applied ai developer building cloudline, a cookieless analytics tool. day 25 of 90, building in public.

the problem i kept avoiding

retention was the setting i never wanted to build. every analytics tool i looked at defaults to keeping everything until you tell it to stop, and most people never tell it to stop. so the default became the product: keep everything, forever.

that default is a liability. old data is the stuff that gets breached. it's also the stuff that ends up in a feature you didn't plan. the privacy conversation is always about what you collect. nobody asks how long you keep it.

what deleting taught me

a delete button you have to press is a delete button you'll forget. so the nightly job presses it for me. boring infrastructure, doing the thing nobody claps for.

there's a side effect i didn't expect. knowing the data expires made me more careful about what i store in the first place. when every field has an expiration date, adding a new one feels like a commitment. i've written before about refusing to build things. the four-field pageview survived that test.

the honest caveat

13 months isn't right for everyone. if your business runs on five-year trend lines, this isn't your tool. i'm not going to pretend one number fits every site. it's the privacy-preserving default for the sites i build for: indie projects, blogs, small products, where last year is the furthest back that matters.

and if you want out entirely, deleting one line of code removes the tracker. the data follows.

the question i don't have an answer to

do you know your analytics retention setting? not the default. the number you actually chose.

most of us inherited it. i'd bet most of us never looked.

day 25 of 90. still building.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

i measure scroll depth without watching anyone scroll

Om Yaduvanshi — Mon, 19 Oct 2026 04:13:38 +0000

your best article has a graveyard at the 40% mark.

most people who open it never reach the end. you already suspect this. the question is whether your analytics can prove it without also proving everything else about your reader.

most scroll-depth tooling comes bundled with the rest of the surveillance kit. heatmaps, session recordings. the scroll number is the excuse and the recording is the product. you wanted one number and you bought a security camera.

cloudline tracks scroll depth as four markers: 25, 50, 75, 100%. when a visitor crosses one, that's a data point. the page, the marker, nothing else. no replay, no heatmap, no pixel path of where the cursor wandered while they read. the interesting thing about a scroll marker is that it doesn't need a who. "somebody reached 75% of this page" is already the whole decision.

i'm om yaduvanshi, 18, an applied ai developer building cloudline, a cookieless analytics tool. day 24 of 90, building in public.

the four markers

a pageview in cloudline stores four things: page, referrer, screen size, time. scroll depth adds the marker crossed. that's the event. four thresholds, coarse by design. finer markers would be more precise. they would also cost more of the visitor's privacy for a number nobody acts on.

coarse numbers are harder to game, too. you can't inflate the number without changing the page, and changing the page is the actual work.

what the markers changed for me

i used to read pageviews and feel good. then i looked at scroll depth on my own articles and felt worse, in a useful way. the drop-off point is the most honest feedback a writer gets. comments tell you what the loudest reader thinks. scroll depth tells you what the quiet ones did. it told me my intros were too long. they were.

pair it with engaged time and you get the full story. time without scrolling is an open tab. scrolling without time is a skim. both together, still no identity, and you know whether the piece landed.

the honest caveat

four markers can't tell you which paragraph lost them. a heatmap could. i don't have heatmaps, and i don't want the data they'd need. if your whole job is squeezing a landing page, this isn't your tool. that's fine. most pages just need to know where the graveyard is.

the question i don't have an answer to

does 100% mean they read it, or does it mean they scrolled fast looking for the link? i don't know. my money is on "looking for the link," but that's a guess. if you run a content site, what does your 100% row look like?

day 24 of 90. still building.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

i grouped every ai chatbot into one traffic source

Om Yaduvanshi — Sun, 18 Oct 2026 04:13:26 +0000

your next hundred visitors might come from a chatbot.

not from google. from a chat window where somebody asked a question and your page was the answer it picked.

cloudline groups its traffic sources: search, social, newsletters, and one more row. "ai assistants."

here is why it is grouped instead of listed per bot.

every referrer you store is a little piece of somebody's browsing history that you now own. a pageview in cloudline stores exactly four things: page, referrer, screen size, time. nothing else, no user agents, no fingerprints. a per-bot breakdown would turn one useful number (how much of my traffic comes from ai) into a detail nobody needs and everybody stores.

so the grouping is the default, and defaults are the product. "ai assistants" answers the question that changes decisions: a growing share of your visitors arrives pre-sold by something that quoted you. which exact bot did the quoting is trivia for most sites.

i'm om yaduvanshi, 18, an applied ai developer building cloudline, a cookieless analytics tool. day 23 of 90, building in public.

the part i like about grouped sources

search tells you what people typed. social tells you who shared it. "ai assistants" tells you something new: your content is being read by machines on behalf of humans. the visitor skips your homepage and lands on the page that answered the question. docs or a specific feature page.

that changes what "top pages" means. your most important page might be the one nobody browses to.

the honest caveat

grouping hides things some people genuinely want. if you are doing seo for ai search, per-bot numbers would be useful. i am not pretending one row fits everyone. it is the privacy-preserving default, and you can argue with defaults. some of you will, and that is fine.

the question i don't have an answer to

do visitors who arrive through a chatbot behave like search visitors, or like referrals from a friend who already explained the product? i don't have enough of them yet to say honestly. if you run a site with real ai-referred traffic, i would love to hear what yours do. genuinely asking.

day 23 of 90. still building.

cloudline is free while in early access. no card.

https://trycloudline.space

— om

i wrote a cookie policy for a product that sets no cookies

Om Yaduvanshi — Sat, 17 Oct 2026 04:10:48 +0000

most cookie policies are confessions written by lawyers. mine is a confession written by me.

i’m om yaduvanshi, 18, an applied ai developer building cloudline, a cookieless analytics tool. day 22 of 90, building in public.

the policy a cookieless product keeps anyway

cloudline sets no cookies. stores no ip addresses. nothing gets saved on your visitors’ devices. a pageview stores exactly four things: page, referrer, screen size, time.

so why does the site have a cookie policy page at all? because not having one looks like you forgot, and looking like you forgot is worse than overexplaining.

what the policy actually says

the short version: there are no cookies to declare, so it says what’s stored instead. four fields. pages stored as path and query only, no fragments, no domain. no user agents. no fingerprinting.

there’s also a “what we’ll never do” list on the features page. it lives on the site, and it means more there than quoted in a blog post.

why write it at all

conventional wisdom says privacy pages exist to satisfy regulators. the honest alternative: for a small tool, the privacy page is the sales page. nobody trusts a one-person analytics product on vibes. they trust it because you wrote down exactly what you collect, in plain words, and there’s nothing surprising in the list.

the page costs nothing to maintain. every time someone asks “but what do you actually store?” i send the link instead of typing the answer.

the caveat

none of this is legal advice. it’s only about my own product: cloudline itself sets no cookies and needs no consent banner for its analytics. i’m not telling you what the law requires anywhere. i write code, not disclaimers.

what i will say: if your tool collects almost nothing, write the almost-nothing down. short and exact. say it plainly and move on.

day 22 of 90. still building.

free while in early access. no card.

https://trycloudline.space

— om

my cookieless analytics knows your device from pixels, not user agents

Om Yaduvanshi — Fri, 16 Oct 2026 04:10:46 +0000

every website you visit files away what phone you have.
you hand it to them yourself, in the user agent string on every page load.
mine throws it away.

i'm om yaduvanshi, 18, an applied ai developer building cloudline, a cookieless analytics tool. day 21 of 90, building in public.

what the user agent actually is

your browser sends a paragraph with every page load. it looks like this:

Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15

phone model, OS version, browser build. every visit, everywhere, unasked.

conventional analytics stores the whole string and derives your device, browser, and OS from it. precise, useful, and quietly identifying. enough of these signals together and you're looking at fingerprinting.

why we don't store it

cloudline stores no user agents and does no fingerprinting. a pageview stores exactly four things: page, referrer, screen size, time. that's the whole receipt.

the screen size does double duty. device type (mobile, tablet, desktop) gets worked out from screen width alone. no cookie, no IP, no user agent string sitting in a database.

the honest trade-off: it's a coarse bucket. a tablet in landscape reads as desktop. foldables are chaos. a vertical monitor reads weird.

but a coarse honest bucket beats a fake precise one. same rule i wrote about on day 16: show the honest number or show nothing.

the part nobody markets

every data point you don't collect is a thing you can't leak, can't sell, and can't be asked to hand over. the settings page for data you never stored doesn't exist. that's the entire privacy argument for not storing user agents. not a toggle. an absence.

what's next, honestly

the roadmap says operating systems and browsers are coming. not shipped yet. countries, core web vitals, weekly email reports — also coming, none shipped.

the question i'm sitting with: how do we add browsers without storing user agent strings? maybe a coarse browser-family bucket, like the device ones. maybe "we don't know" stays where it is. i'd rather ship the coarse honest bucket than a fake precise one, and i'd rather ship nothing than a bucket i can't defend.

day 21 of 90. still figuring out the line between knowing enough and knowing too much.

free while in early access. no card.

https://trycloudline.space

— om