Hi everyone!
Last week I had interesting discussions with some Chiffre users about the Origin filter feature. It's something I had put in place early on, to prevent "spam analytics" coming from other domains than your production website. This could happen for many reasons:
- Local development (from localhost, 127.0.0.1)
- Preview URLs
- Staging environments
My initial assumption was that a project was tied to a particular deployment, and you'd use additional projects if you really wanted to measure a staging environment. But that assumption did not take account limits into consideration at the time, so it does not work anymore. (ICYMI: we discussed limits in week 4 of this newsletter).
We can't allow every single domain to push stats to your analytics dashboard unchecked, as website hijacking is unfortunately a thing.
The other issue is that new users of Chiffre have usually tried it on a staging domain, and wondered why their analytics were not counted.
There are several options here:
- Allow every origin by default on project creation
- Let the user change the origin filter in the project settings
- Use glob patterns and wildcards for origin filtering (eg:
*.mydomain.now.shfor Vercel deployments)
Origin scoped analysis
We could go a step further and store the origin along with the message, and let the webapp choose whether to analyse it or not.
This could look a bit like Stripe's Test / Live switch: you have your test analytics for local development, preview deployments and staging environments, and live analytics for production.
This would make a lot of sense when integrating with Chiffre's custom events function, to test goal tracking.
One issue with this approach is that the Origin header is not always present, some browsers simply don't send it. We could instead rely on the tracker script to capture the value of location.hostname and send it along with the message.
DNT
There was some discussion on Hacker News about the relevance of honouring DNT, which I have listed as a feature on the landing page.
What happens when a visitor's browser emits a "Do Not Track" signal is the following:
- A single event is sent, containing the time and country of origin. Nothing else, not even the page they landed on.
- No other events are sent throughout the whole visit (no page views when navigating on the website, no time on site at the end of the session).
This is obviously very limiting, as it does not bring much information. At the very least, I could add the page the visitor landed on, to count in page views.
The definition of "tracking" can be very broad, and cover lots of aspects. Obviously, Chiffre does not (and cannot) do cross-site tracking, as we don't use cookies nor use IP addresses at any point.
Same-site tracking (following a visitor across their movements on the website) can be desirable, so this might be something I could allow as an opt-in behaviour for the site owner, with an opt-out for the visitor.
Dataviz
Last week I started working on a small library to graph values over time, locally and with a simple API. I'm planning on using it to graph and measure my progress on the Web Workers performance improvements.
Amusingly, it's borrowing some concepts from Chiffre itself: an IndexedDB time series database, aggregated graphs and dynamic recalculation when the underlying data is updated:
I will keep polishing the API and post it as an open source TypeScript library on my company's organisation on GitHub, 47ng, where I keep a lot of other things that I have open-sourced after needing them on more than one project (building Chiffre led me to open-source 25 projects in a year 🎉).
Stats
Things are a bit quieter this week:
- 😐 11 users (same as last week)
- 📈 17 websites (+1 since last week)
- 🐦 38 followers on Twitter (same as last week)
- 💌 29 subscribers to this newsletter (+4 since last week)
- 📊 17500 events processed (+2000 since last week)
See you soon, and take care.
François Best
Founder | Chiffre.io