We recently released a new algorithm increment with expenditure modifiers, and we’re excited for you to try it out! In this article, I’ll explain what they are, how they work, the impact they’ll have on your recommendations, and another small change to MacroFactor’s nutrition recommendations.
The new additions build upon the success of the V3 algorithm. If you’d like a big-picture overview of how the expenditure algorithm works, and the types of problems we have to solve to optimize the performance of the algorithm, you should give this article a quick read. V3 was a pretty significant overhaul, whereas the expenditure modifiers are more of an expansion and refinement of the system we built for V3. So, I won’t be rehashing everything covered in the previous article; instead, I’m just going to hop right into the changes and updates.
Change #1: Small tweaks within the existing framework
The first change is that we slightly tweaked the weights of several of the variables that were already used to generate expenditure updates in V3 of the expenditure algorithm.
As discussed in the previous article, there’s an inherent tradeoff between stability and responsiveness of the expenditure algorithm. But, these tradeoffs are nonlinear. An extremely responsive algorithm tends to be more accurate than a less responsive algorithm when its outputs are averaged over any reasonable period of time. But, this increase in accuracy comes at the expense of day-to-day unusability, since your Calorie targets would regularly increase or decrease by several hundred calories every week.
Using a shorter lookback window is one way to make an algorithm more responsive. This graph from our prior article visually illustrates the pitfalls of maximizing responsiveness at the expense of stability.
Conversely, a maximally stable algorithm would never update your expenditure at all, leading to very poor accuracy, on average.
Using a longer lookback window is one way to make an algorithm more stable. This graph from our prior article visually illustrates the pitfalls of maximizing stability at the expense of responsiveness.
We can visualize these tradeoffs by plotting an efficiency curve.
For responsiveness, the metric we’ll use is average absolute monthly weight change error: the extent to which monthly weight change differs from what the expenditure algorithm tacitly predicted, based on your Calorie intake. This is technically a metric to assess algorithmic accuracy rather than responsiveness per se, but increased accuracy is the entire point of increasing responsiveness, so it serves as a good proxy (i.e., if an algorithm got more “responsive” without also getting more accurate, it’s not “responding” to whatever it’s supposed to be responding to).
For stability, the metric we’ll use is the average absolute daily expenditure change: the typical amount of day-to-day change in your calculated expenditure.
Here’s the resulting efficiency curve for an algorithm built upon the same principles as MacroFactor’s V2 algorithm:
On this graph, values closest to the bottom left corner are ideal, offering the best blend of accuracy and stability. This coincides with the part of the graph with the prominent bend. So, let’s zoom in on that region to see how the tweaks made in the recent update impact this tradeoff.
First, I’ll start by plotting the stability versus responsiveness relationship using the prior weights of the V3 expenditure algorithm. As you can see below, the upgrades in V3 allowed us to push beyond the efficient frontier of the V2 algorithm, achieving a blend of responsiveness and stability that was previously unachievable.
The precise gains in responsiveness and stability will be contingent on the dataset used for testing purposes (in this case, I’m using the first 100 days of data from new MacroFactor users who participated in our New Year’s Challenge), but within this dataset, the V3 algorithm is about 19% more responsive than a V2-style algorithm with similar stability, and about 20% more stable than a V2-style algorithm with similar responsiveness.
So now, let’s see the impact of the small tweaks we made to the weighting variables that were already present in the V3 algorithm.
Like I said: they were quite small tweaks. The net effect is that they reduce stability by about 3.9%, while increasing responsiveness by around 5.8%. I won’t pretend like this isn’t a fairly small change, but it’s a slightly bigger change than meets the eye.
For starters, through this region of the responsiveness versus stability curve, any gains in responsiveness typically come with a disproportionately larger decrease in stability (i.e., you’d expect a 5.8% increase in responsiveness to reduce stability by around 7%, give or take).
Additionally, this curve depicts average absolute error versus average daily expenditure change over the entire 100-day period for the contest participants, but a pretty large chunk of the total error during that period comes from the first 30 days of using the app (before the expenditure algorithm is fully calibrated for the user). And, during that initial calibration period, you should expect expenditure updates to be larger (larger updates mean that any initial estimation error is being mitigated quicker).
So, for a better idea of the net improvement for most users, it’s helpful to focus on the stability versus responsiveness tradeoff from day 30 onward. And, after the 30-day initial calibration period, these tweaks result in 6.9% better responsiveness, compared to a 2.6% decrease in stability. In other words, these tweaks lead to modest net improvements for brand-new users, and somewhat larger net improvements for people who’ve already been using the app for a while.
Change #2: Incorporating step count data
For the first time, MacroFactor’s expenditure algorithm will directly incorporate activity data if you enable “Step-Informed Updates.” To enable this modifier just go to More > Expenditure (under Feature Settings) > Step-Informed Updates (under Expenditure modifiers) and toggle the modifier on.
For the time being, we’re only using step counts. The reasons for this decision are pretty straightforward:
- If you have a smartphone, you also have a reasonably accurate pedometer – using step count data doesn’t require people to buy an additional product to reap the benefits.
- Even if you have a smartwatch, you have a device that’s quite good at measuring step counts, and quite bad at estimating energy expenditure. When given the option, we lean in favor of using more accurate data sources.
Note that step counts won’t be used to additively increase or decrease your calorie targets on individual days. Rather, step data will be incorporated into MacroFactor’s algorithms in a manner similar to the data you’re already logging (weight and nutrition data), meaning it will smoothly and progressively increase or decrease your estimated expenditure and calorie targets over time.
It actually took quite a bit of testing to find a way that step data could be used productively, since the expenditure algorithm already works quite well with just the use of weight and nutrition data. More often than not, activity levels are associated with energy status and weight change status (in other words, if you’re eating less and losing weight, you tend to also move less, and vice versa when you’re eating more and gaining weight). Furthermore, due to the effects of energy compensation, changes in activity levels tend to impact energy expenditure a bit less than you might otherwise expect, especially when you’re losing weight. When we’ve said that MacroFactor’s algorithms didn’t need activity data to function well, we weren’t bullshitting.
However, we did find a way for step data to slightly improve the performance of the expenditure algorithm. Much like the tweaks discussed above, however, the impact was quite small. Here it is, plotted on the same efficiency curve we used previously.
On the surface, we’re looking at a ~3% decrease in stability, compared to a ~2% improvement in responsiveness (on top of the changes resulting from the previously discussed tweaks). Once again, the upside becomes more apparent after the 30-day mark, where the decrease in stability is still only 3%, compared to a 3.3% increase in responsiveness.
Compared to expenditure V3, these two tweaks combined increase responsiveness by nearly 11%, while reducing stability by a bit less than 6%.
Change #3: Accounting for new goals
Last year, we published a series of articles about Basal Metabolic Rate (BMR), culminating in the release of our new BMR equation (and calculator).
In two of those articles, we discussed how weight gain and weight loss impact BMR. But, BMR changes only account for a fraction of the excess changes in total energy expenditure resulting from attempts to gain or lose weight. However, there’s quite a bit of research documenting the effects of weight gain or weight loss on BMR, but there’s considerably less research comprehensively documenting the effects of weight gain or weight loss on excess changes in total energy expenditure.
So, I’ve been pretty sure that MacroFactor’s initial expenditure estimates tended to slightly overestimate energy needs for people aiming to lose weight, and tended to slightly underestimate energy needs for people aiming to gain weight. But, I was hesitant to make any adjustments to MacroFactor’s initial expenditure estimates without first having the necessary data to inform those adjustments.
However, the data from participants in MacroFactor’s New Year’s Challenge provided me with a large dataset to address the problem.
MacroFactor’s expenditure algorithm is, functionally, a prediction engine. If your energy intake matches your estimated expenditure, MacroFactor is tacitly predicting that you’ll maintain your weight. If your energy intake is above or below your estimated expenditure, MacroFactor is tacitly predicting that you’ll gain or lose weight (respectively), and it’s predicting the rate at which you’ll gain or lose weight. The degree to which your estimated expenditure increases or decreases over time is more-or-less determined by prediction errors. If you lose weight faster or gain weight slower than would be predicted based on your current estimated expenditure, that implies you’re burning more energy than was previously predicted, so your estimated expenditure will increase (and vice versa if you gain weight faster or lose weight slower than would be predicted).
So, to determine if MacroFactor’s initial expenditure estimates are too high when people set a weight loss goal, and too low when people set a weight gain goal, all I had to do was compare people’s target rate of weight change to the weight change estimation error during their first month of using the app.
Here were the results.
Now, this is obviously a noisy dataset, but it’s also a very large dataset. Though the correlation was fairly weak (r = 0.27), it was associated with a p-value of p < 0.00001.
To correct for this bias, the initial expenditure estimate needed to be multiplied by four-times the intended rate of weight change (as a percentage of body weight per week). In other words, if someone was aiming to lose 1% of body weight per week, their initial expenditure estimate needed to be 4% lower.
Applying this correction eliminated the bias seen in the graph above:
This correction comports pretty well with the research that does exist on the topic.
In tightly controlled studies, weight loss appears to lead to ~10-15% reductions in total energy expenditure beyond what one would expect based solely on changes in fat and lean mass (i.e., total energy expenditure winds up 10-15% lower than standard TDEE equations and calculators would predict).
Our BMR equation already assumes that BMR will be 5-8% lower when losing weight. This 5-8% reduction in BMR already leads to a 5-8% reduction in total estimated energy expenditure, since we initially estimate expenditure by estimating BMR, and then multiplying that value with an activity correction factor (i.e., 0.92 × 1.5 is still 8% less than 1 × 1.5). Furthermore, the typical intended rate of weight loss tends to be around 1% for most users, which would lead to an additional 4% decrease in our initial expenditure estimate. A 5-8% reduction due to the BMR equation, compounded with an additional 4% reduction, would lead to a total reduction in initial expenditure estimates of around 10% (8.8-11.7%). And, if someone was targeting an aggressive rate of weight loss closer to 2%, the additional 8% reduction would lead to a total reduction in initial expenditure estimates of around 15% (12.6-15.4%). So, this adjustment produces values that are in line with what we’d expect from the literature.
Bringing back the “Efficient Frontier” graph, here’s the impact of also adding in this modifier.
The net effect: a 9.1% increase in responsiveness compared to V3 without modifiers, with no meaningful change in stability. The new version of the algorithm with both modifiers enabled is nearly 30% more responsive than a V2-style algorithm with similar stability, and about 29% more stable than a V2-style algorithm with similar responsiveness.
Past the 30-day mark, the overall change compared to V3 with no modifiers is a 10.7% increase in responsiveness, compared to a scant 3% reduction in stability. And, just to put a 3% stability reduction in perspective, the average daily expenditure change (in this dataset) was 7.25 Calories per day with V3 (and no modifiers), versus 7.49 Calories per day with both modifiers enabled. I tend to be fairly obsessive about trying to improve each version of the expenditure algorithm in all metrics, but users were already very happy with the boost in stability when transitioning from V2 to V3, and I doubt that a grand loss in stability of less than a quarter of a Calorie per day (on average) will even be noticeable.
Also, I think these metrics probably undersell the boost in performance users will experience with this new version of the expenditure algorithm. After all, the title of this section is “Change #3: Accounting for new goals,” not “Change #3: A tweak to our initial expenditure estimates.”
The same correction that improves initial expenditure estimates can also be applied when you set a new goal in the app, which is where the second expenditure modifier comes in: “Predictive Goal Adjustment.” We know that your expenditure is expected to increase when you switch from losing to gaining weight, and decrease when you switch from gaining to losing weight. So, if you’re currently losing 1% of your body weight per week, and you set a new goal to gain 0.5% of your body weight per week, the expenditure algorithm will be able to take this into account, and proactively nudge your expenditure (and your resulting calorie targets) up by an additional ~6% over the course of a couple of weeks. This will reduce the lag time some users experience between the time they set a new goal, and the time their weight starts increasing or decreasing at their desired rate.
To enable this modifier, just go to More > Expenditure (under Feature Settings) > Predictive Goal Adjustment (under Expenditure modifiers) and toggle the modifier on.
Quantifying the impact of the modifiers
In a recent article, we discussed the accuracy of the V3 expenditure algorithm. So, how much do these modifiers actually improve algorithmic performance?
For starters, enabling both modifiers reduces monthly weight change absolute prediction error by around 6% overall, and around 8% after the initial adaptation period.
The cumulative impact of this persistent edge in accuracy compounds over time. Over the full 100 days, cumulative daily weight change prediction error is reduced by nearly 20%.
As a result, even more people wind up with estimation errors below 5%, 10%, and 20% of TDEE.
So, in total, the modifiers make the algorithm about 6-8% more accurate in the short-term, and nearly 20% more accurate in the long-term. Though, it’s worth acknowledging that the V3 algorithm without modifiers is already exceptionally accurate in the long term. In real terms, the median weight change prediction error over 100 days shrinks from a little over 3lb without modifiers to approximately 2.5lb with modifiers (meaning the median expenditure error over 100 days is about 108 Calories without modifiers versus 89 Calories with modifiers). So, not a night-and-day difference, but still a very solid, tangible improvement.
One other small tweak: slightly increased protein recommendations
Bundled with this update, we also adjusted our protein recommendations to better align with evolving evidence on the topic. Namely, protein recommendations increased slightly for lifters (users who indicate that they regularly engage in resistance training) who are either bulking or maintaining, with larger increases for lifters who are cutting and prefer higher protein intakes.
| Updated protein recommendations for lifters (grams per kilogram of FFM) | ||||
|---|---|---|---|---|
| Goal | Protein Category | Old | New | Change |
| Bulking or Maintaining | Low | 1.75 | 1.75 | 0 |
| Moderate | 2.2 | 2.35 | 0.15 | |
| High | 2.65 | 2.75 | 0.1 | |
| Extra | 3.1 | 3.1 | 0 | |
| Cutting | Low | 2.05 | 2 | -0.05 |
| Moderate | 2.4 | 2.5 | 0.1 | |
| High | 2.75 | 3 | 0.25 | |
| Extra | 3.1 | 3.5 | 0.4 | |
And, that wraps things up! These updates highlights our focus on consistently updating and improving our core systems on the basis of ongoing internal research and emerging external evidence, in order to help MacroFactor users achieve the best possible results.
