Jul 5, 2026
Why I built my own analytics instead of using an existing tool, and what it takes to treat privacy as something you design for rather than comply with.
Building your own analytics is usually a waste of time, and I would not recommend it, but for VineWall I did it anyway.
Most analytics tools treat privacy and transparency as a compliance checkbox, VineWall needs more than that.
What is missing?
Compliance and privacy overlap, but they are not the same thing.
Much of what the law requires does protect people, and some of the strongest protection isn’t required by anyone. Clearing the legal bar tells you a company did what was required of it, it does not tell you what it built to protect the people behind the data.
When you look at how analytics tools describe their privacy, that distinction disappears. Ask what a tool does for privacy and the answer is usually the list of laws it complies with. Much of what VineWall needs lives in the part the law doesn’t require, and that is the part most tools never reach.
Guiding principles
My first priority was to come up with a cool name for the analytics (Corvo), then my second priority was to define the guiding principles of Corvo.
Corvo is explicit by default, a feature does nothing until it is loaded and switched on.
It relies on defense in depth, one slip should not be enough to leak data. Forget to mark a field as sensitive, and the sanitizer strips it before it leaves the device.
And it treats transparency as a feature. “We only collect a limited amount of data” sounds hollow unless you can show people exactly what is logged and why.
Corvo features
Each of these is one of those principles in practice. Most analytics tools don’t offer them, or offer only a limited version.
Hashing every sensitive field
The foundation of Corvo’s privacy is that every sensitive field (ips, user ids, app names) is hashed on the device, before it leaves, using HMAC-SHA256 with a secret unique to that device.
The hash is keyed because these values have low entropy. An ip or an app id comes from a small, enumerable set, so a plain hash of one could be recovered by trying every possible value. A keyed hash can’t be reproduced without the device secret, so that doesn’t work.
The server then hashes the result a second time with a secret the device never holds, kept separate from the database. A database leak on its own exposes only these twice-hashed values. Even with a leaked device secret, an attacker could recompute the device-side hash for a guessed value but not the server’s hash on top of it, so the guess still can’t be tied to a stored record.
The double hashing itself isn’t unique, TelemetryDeck does something similar. The difference is that Corvo double hashes every sensitive field, not just the user id.
Sanitization
A field is hashed because it was marked sensitive, but people can make mistakes, and a field not marked as sensitive, like an error string, can reach the payload with an app name or an ip inside it.
Sanitization is the catch for that, scanning the non sensitive fields before the payload leaves the device, and when a value looks sensitive it drops the entire field. It works off patterns, so it only recognizes familiar shapes, but its an additional layer of safety.
Data collection report
Every privacy policy asks you to trust a sentence about what it collects, Corvo shows you the list.
The data collection report names every field Corvo logs in plain language, with the reason each is there, and because it is generated from what Corvo is set up to collect rather than written by hand, it stays in step with what the app actually does.
Anyone using the app can open it and read the whole thing.
Writing the report does one more thing while you build it: every field needs a reason written next to it, and if you can't write a good one, you probably shouldn't be collecting that field.
Corvo trade-offs and shortcomings
Corvo works in a particular way, and that comes with trade-offs. The first is the setup: because every feature has to be turned on explicitly, getting it running takes more work than a drop-in SDK where you add a key and move on.
The second comes from the anonymity. With no stable identifier surviving the hashing, there is no way to tie activity to an ad click or a marketing campaign, so that kind of attribution is off the table. For VineWall that is fine, it was never the goal, but it is a real thing the design gives up.
Was it worth it?
Yes, because it was what VineWall needed, and nothing off the shelf was going to give me that.
What I’m hoping for is the day this isn’t worth doing anymore, when analytics tools lead with how well they protect people rather than the compliance they can advertise, and building it in this deeply is just what they do.
We’re not there yet, but I hope we eventually do.
END