惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
云风的 BLOG
云风的 BLOG
博客园 - 聂微东
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
P
Proofpoint News Feed
GbyAI
GbyAI
WordPress大学
WordPress大学
NISL@THU
NISL@THU
V
Vulnerabilities – Threatpost
T
The Exploit Database - CXSecurity.com
D
DataBreaches.Net
F
Full Disclosure
Recent Commits to openclaw:main
Recent Commits to openclaw:main
V
Visual Studio Blog
Last Week in AI
Last Week in AI
L
LangChain Blog
AWS News Blog
AWS News Blog
Martin Fowler
Martin Fowler
V
V2EX
The Hacker News
The Hacker News
Scott Helme
Scott Helme
T
Troy Hunt's Blog
G
GRAHAM CLULEY
L
Lohrmann on Cybersecurity
Cloudbric
Cloudbric
C
Cyber Attacks, Cyber Crime and Cyber Security
O
OpenAI News
月光博客
月光博客
博客园_首页
Blog — PlanetScale
Blog — PlanetScale
B
Blog RSS Feed
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google Online Security Blog
Google Online Security Blog
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
G
Google Developers Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
IT之家
IT之家
C
Cisco Blogs
Google DeepMind News
Google DeepMind News
T
Tenable Blog
Jina AI
Jina AI
T
Tor Project blog
The Cloudflare Blog
Y
Y Combinator Blog
Spread Privacy
Spread Privacy
L
LINUX DO - 热门话题
Cyberwarzone
Cyberwarzone
Microsoft Security Blog
Microsoft Security Blog
Stack Overflow Blog
Stack Overflow Blog
A
Arctic Wolf

Adactio

June 16th, 2026, 11:12am June 16th, 2026, 10:16am Enhancing with CSS Grid Lanes How building an HTML-first site doubled our users overnight Speaking in Dublin June 13th, 2026, 9:09pm A tale of two browsers Sarah Canary by Karen Joy Fowler June 12th, 2026, 5:59pm The Field Guide to CSS Grid Lanes June 12th, 2026, 12:24pm June 12th, 2026, 8:58am June 11th, 2026, 6:22pm June 11th, 2026, 6:20pm June 10th, 2026, 6:25pm June 10th, 2026, 10:14am June 9th, 2026, 8:50pm June 9th, 2026, 1:55pm June 8th, 2026, 7:45pm June 8th, 2026, 4:32pm Amsterdamming June 5th, 2026, 3:16pm June 4th, 2026, 8:21pm June 2nd, 2026, 8:37pm 25 years of The Session Happy Monday everyone, and let's talk about gender and ethnicity ratios at tech events. AI and the Rise of Mediocrity May 28th, 2026, 7:24pm Picture at an exhibition May 27th, 2026, 9:41pm May 27th, 2026, 1:52pm May 25th, 2026, 8:03pm Gaeltacht cois Tamaise 2026 May 25th, 2026, 3:07pm May 23rd, 2026, 8:06pm May 23rd, 2026, 8:31am May 22nd, 2026, 3:38pm May 22nd, 2026, 8:19am May 22nd, 2026, 7:22am May 21st, 2026, 8:19pm Brigid by Kim Curran May 20th, 2026, 7:12pm The value is in the difficulty - Annotated May 17th, 2026, 6:21pm May 15th, 2026, 4:19pm Tito as Gaeilge The closing talks at UX London 2026 Native Apps Should Be Avoided Whenever Possible — No One's Happy WebKit Features for Safari 26.5 May 11th, 2026, 4:17pm I knew my writing students were using AI. Their confessions led to a powerful teaching moment | Micah Nathan Gideon The Ninth by Tamsyn Muir May 8th, 2026, 3:55pm Better Browser Caching with No-Vary-Search May 7th, 2026, 9:55am May 7th, 2026, 7:49am The schedule for UX London 2026 Google’s Prompt API Reminder: You Can Stitch Together Lots of Little HTML Pages With Navigations For Interactions Netizen | Derek Sivers April 30th, 2026, 7:59pm April 29th, 2026, 8:12pm April 27th, 2026, 7:47pm April 25th, 2026, 12:03pm April 25th, 2026, 12:00pm April 25th, 2026, 8:03am April 24th, 2026, 7:57pm April 24th, 2026, 5:12pm Two Paradigms for Enhancing HTML Tags Summary punishment It's Not AI. It's FOMOnetization. Alistair Davidson / validation-enhancer · GitLab Never Lose Form Progress Again :: Aaron Gustafson Dilation Expansion artifacts April 19th, 2026, 6:03pm Finn Mac Cool by Morgan Llywelyn April 17th, 2026, 7:58am April 16th, 2026, 6:42pm Threat models No-stack web development Design and Engineering, As One · Matthias Ott April 14th, 2026, 7:21am April 13th, 2026, 7:47pm April 11th, 2026, 8:39am April 10th, 2026, 5:36pm My salary history Conference organising in 2026 April 7th, 2026, 8:32pm TinyStart AI Might Be Our Best Shot At Taking Back The Open Web | Techdirt April 6th, 2026, 12:46pm The AI Great Leap Forward April 4th, 2026, 6:42pm April 3rd, 2026, 5:27pm April 2nd, 2026, 8:58pm April 2nd, 2026, 4:32pm Web Day Out - 12 March 2026 Mistrust HTML Video Poster Image: Enable Responsive Images and ALT Text for Poster
Three things about data
Russell Davies · 2026-05-15 · via Adactio

Some recent conversations have reminded me that I have opinions about data and its use inside organisations. Especially for marketing-type stuff.

Here are three of those opinions

Gather less of it

A few years ago in a sales meeting some ad-tech person said 'I bet you wish you had more data on your customers' and the my perpetually contrary inner voice said 'oh no I don't, I wish I had far less'. I may have actually said it. I may have said 'No I don't, I wish I had less, and if you came to me promising an effective service with far less data I might have been interested.'

That's what I'd have said now.

Because:

a. Data is a risk. Every bit of data has to be managed/looked after/cared for. That costs time and money. And most of it is useless.

b. Data is distracting. Most of it is just noise. You're gathering it because you can, just in case, because it seems valuable. Then you spend ages trying to work out what to do with it. When you should be paying attention to just a couple of bits of it and actually doing something about it.

c. It becomes a job. Get enough data and you need data scientists. Then you're stuck in a self-perpetuating structure that requires more data to feed the data scientists.

The best expression for all this I've ever seen is from James Timpson, a column in The Sunday Times towards the end of the pandemic. Here's a (long) excerpt:

"I vividly remember being shown the charts room in fund manager Fidelity’s huge London office. There were graphs of everything under the sun. Was the theatre of the chart room the big sell to clients, or was it a useful tool for the analysts? No doubt Debenhams’ bosses had lots of facts at their fingertips, but data didn’t help them save the business.

Now our shops are open again and everyone is back at the office, the data is pouring forth. We have a culture where we want to produce as little information as possible, but it can feel like watching a dripping roast, with statistics flowing from every department at an alarming rate. With 2,100 shops, there’s always lots of information to consume and my eyes can quickly glaze over.I prefer to focus on a few things, as well as the basics of retailing. Are the shops open? Is everyone happy? If so, we can start taking money.

There must be a point where the costs of interpreting and using data exceed the benefits of collecting it. Can you afford a chief data officer paid £120,000 a year plus bonus? We can’t, so instead we have three simple ways of understanding what’s going on.Every night at 7pm, I get an email listing that day’s sales. This data isn’t collected by an “Epos” (electronic point of sale) till system, but by colleagues filling out a form online. They also write the sales numbers on a piece of paper and keep it on a bulldog clip. This takes five minutes a day. It sounds old-fashioned, but when people physically write things down they seem to take more notice. If you ask our colleagues what their sales are so far today, I bet they’ll know to within the nearest £50.

Over the past 25 years, we have acquired a number of (loss-making) retail chains. The first thing we do is switch off their Epos tills. All we need is a drawer to keep the cash in and a calculator to add up the sales. We have thrown away more than £8 million of kit — and it’s made life easier for us.The businesses we bought were often collecting vast amounts of data from their fancy tills, yet the managers were actually reading very little of it, and it rarely helped colleagues give better customer service. As sales plummeted, they analysed more data, and brought in more finance experts and consultants to work out where the problems were. Redundancies weren’t made from the data team — it was the people on the front line, serving customers, who lost their jobs first. These companies failed because they lost focus on what’s important: great customer service.

So our second barometer is customer service scores, which I look at every day. We ask customers to use an online form to rate their experience out of ten (our average score last week was 9.4). Every colleague sees their feedback in real time, and if we get a bad score our area managers are expected to call the unhappy customer straight away to apologise and fix the problem.

One piece of data beats everything else. A quarter of a century ago, my dad taught me the best way to measure the health of our business was to look at the cash figure every day. Each morning at 10am, I get an email from Caroline in the finance team showing the cash we have in the bank compared with the same day last year. This fact offers no hiding place."

Here's the whole thing

Keep it in your hands

Data is most useful when it's in the hands of the teams who create it or need it. The more it gets abstracted away to other teams and other softwares the more dangerous and misleading it gets.

So start off with writing it on pieces of paper or sticking it on the wall. Graduate to spreadsheets only when you have to. Move on from spreadsheets very, very reluctantly. Dashboards are dangerous. Everyone knows the stories about pilots flying into the ground while staring at their instruments. Dashboards abstract away the reality.

The trick is to keep the data in your hands. Get it from the source yourselves, regularly, daily, weekly and copy it into your spreadsheets then get together and talk about what you're seeing. Yes, you might have transcription errors but you should catch them because you know the data directly.

You know, because you've been sticking it in a spreadsheet every week, how many subscribers you have. Or whatever. That's different to seeing it go green on a dashboard or seeing the lines on a pie chart move.

This has the additional advantage of matching the fidelity of the presentation to the quality of the data. When you don't have much data - and therefore don't know much - then keep it scratchy and on paper. It might look less whizzy but it reminds you of the uncertainty. There's a massive risk in taking the tiny amounts of data that startups have and pasting it into fancy dashboards and vibe coded analytics. You start forgetting you've got a tiny sample size.

Translate to human

I used to have regular rows with engineers who told me that various things they'd built worked for 99% of our customers and were therefore ready to go. But, I'd say, we've got two million customers, so twenty thousand people are about to be massively inconvenienced and most of them will phone us.

You have to think through the data to the people-sized reality.

I find two things help with that:

  1. How many Wembley stadiums?

Numbers of people are hard to visualise. It helps if you think of things you've actually seen. Like 'that's the same number of people who can fit in Wembley stadium'. You might realise that a number is bigger, or smaller than you thought.

  1. Talk through the reality

Check the data by imagining the story behind it. Say, out loud, in your data meeting, what you think might be happening. So, if you've changed something on your emails and the click-through rate is going down then talk it though 'I think this means that people aren't sure what they'll get when they click so they're reluctant to do it. Does that make sense?' It doesn't have to be right, it just has to be plausible. Because if you can't think of a plausible explanation for what's happened you need to revisit the data or check some assumptions.