“I know that major API changes are always a pain for developers and they would rather not have to deal with them, but please keep in mind stats like “42% of malicious extensions use the Web Request API” when you’re considering what we’re trying to improve here.”
Google is using a large number—42% of malicious extensions—in isolation to justify a decision. This number shows that a large proportion of ‘bad developers’ use this API. But this single data point gives no clue about how big is the total pool of developers using this API.
Are bad developers a large proportion of users of this API, or are they a tiny minority? In the latter case, Google’s action to deprecate/restrict the API may be fairly justified. In the former case, they could have chosen a better, alternative approach in dealing with the bad actors, rather than punishing the mostly good users.
An analogy for case 1:
Bank decides to close all doors leading to the street because 42% of all robbers walk-in through those doors.
Analogy for case 2:
Bank decides to close all waste disposal tunnels because 42% of all robbers sneak-in through those doors.
All we know is that 42% of robbers come in through a point. We don’t know if it’s the main customer entrance, or the waste disposal.
If this statistic was a big argument for this decision’s approval inside Google/Chrome-Dev, then they really need to revisit their decision-making fundamentals.
I seriously doubt this though. Googlers are very smart. They are dealing with mostly smart people on the outside. This number is not for them or us. This number is being published solely to turn the narrative, for the common reader, from ‘Google blocking APIs that stop ads and tracking‘ to ‘Google blocking APIs that stop malicious extensions‘.
This is what greeted me when I tried to comment on Fred Wilson’s post today.
Fred Wilson wrote about signing up to Pocket, and requested suggestions for becoming a power user. Naturally, I wanted to comment with a plug for my Chrome extension for Pocket. I also wanted to offer my 2c on why I found Instapaper better than Pocket 1.
Income tax rates are based on current/last year’s income. This makes them easy to calculate and implement.
This immediacy of taxes also makes them painful, and makes the tax slab thresholds as artificial barriers to income mobility. An example of this is when we get a raise which pushes us from near the top end of one tax rate bracket, to the bottom end of a higher tax rate bracket. This frequently means that even though the employer is paying us more after the raise, we are actually taking home less money due to a higher tax rate.
Government benefits work similarly. For example, the unemployment benefit / social support payments cut off (or reduce dramatically) when we start working. However, after accounting for taxes and loss of benefits, the take home income from pay is often lower than the unemployment benefits.
This headline reminds me of the old principle that I emphasise:
Money is the final metric
If our metrics don’t directly correlate to, or convert into money1 in the near term, then they are not the correct metrics.
Too many metrics, in my experience, are designed for being:
easy to measure (or easily available),
easy to improve, and
comfortable to explain
What they are not designed for: being strongly correlated with current or future supply of money.
For growth, revenue (total, unit, net unit) is the best metric.
Views of our videos2 can be good metrics if they convert directly into money:
– product sales show a direct correlation, or
– advertisers accept them as proxy for ad views, or
– investors require them as a valuation input for the next raise
Views of our videos are a bad metric when they aren’t directly impacting revenue. If sales aren’t growing in proportion with the views, then counting views is of no relevance to the health of the business.
The availability bias trip-wire
The availability heuristic operates on the notion that if something can be recalled, it must be important, or at least more important than alternative solutions which are not as readily recalled.
Most online advertising platforms understand this well, and use it to hook their customers (advertisers). If they show us good3, clean and easily accessible metrics of their choice, we will give those metrics more weight than they deserve.
The views count is right there – in the analytics dashboard. While finding the correct metric that actually correlates with sales, and then tracking it, can be hard.
This also ties in the second part of the hook. The view count number is also easily movable. Spend some money on advertisements, the view count will go up. Voila! View counts – a metric that is easy to measure, and easy to improve!
Those money-correlated metrics, they are even harder to improve than they are to discover and track. Oh look, the views went up again!
We all have heard of ‘Our viewer/user/visitor numbers were amazing, but the money ran out before…’
This is why the money ran out. Because we chose the easy metric, over the metric that really matters – money.
Values to be averaged are in A1:A99, corresponding dates are in B1:B99.
What the formula does: average the values in the range – Include a value in calculating average for the current date if:
The date for that value is same as or before the date in the current row, and
The date for that value is greator than the date X days before the date in the current row (X is 30 in the formula for a 30-day moving average)
The long one:
I have a spreadsheet with my daily weight log. It has occasional missing days – when I didn’t log my weight.
Yesterday, I wanted to chart this data, and wanted to add a moving average to it. Google sheets’ in-built moving average trend line refused to work – either due to the missing data, or due to the number of entries. So I added a column to the sheet with the calculated (trailing) moving average weight.
I’ve never before had to calculate moving average over a non-consecutive data set. So, in case I forget, I’m noting it down here for later…