Issue on docs: Weighted sum documentation unclear on edge cases.

[deefdragon]

Path: /guide/billable-metrics/aggregation-types/weighted-sum

First: How weighted sum resets per-billing period is confusing. Given the whole point is to calculate a weighted average, knowing which option to select for metered vs recurring, and how things are impacted for the next invoice is difficult.

Examples of how the invoices would be calculated going beyond the single invoice boundary would be appreciated for the metered and recurring cases.

Secondarily, the graphic on the page that has the A,B,C, & D segments could also be labeled better as to what is happening at each point. Is A setting the value to 1, or to 2? Is the 1 a leftover value from the previous period etc.

[deefdragon]

clarification of problem

I think my initial issue was a bit chaotic and unclear, largely due to because I was misinterpreting how weighted_sum functioned. Specifically, the graphic on the documentation page implied to me that the operation of weighted sum operated where it summed up the values after applying their weights, not that each metric is added together as time goes on, and then those sum values are weighted.

The issue mentioned here that was marked as completed is similar to what I was assuming I could do, and I believe #155 is also raising a similar issue.

Lets take a specific example. I have a user with 10GB of data stored. They add 5GB (up to 15 GB) 10 days into the month. They add 5 more GB up to 20GB another 10 days in. Finally, 5 days later, delete all but 5 GB of data.
That means they have
day 0 10GB,
day 10 15GB,
day 20 20GB,
day 25 5GB and
day 30 still 5GB (when they are billed).

Assuming $1 per GB/month, $1010/30+$1510/30+$205/30+$55/30 they should be billed a total of $12.50.

The graph implies a similar situation,
day 0 was 1 unit,
day 1 was 2 units,
dat 1.5 was 3 units,
day 2 was 1 unit,
day 4 (the end) was still 1 unit.

As such, the graph showing how the weighting works makes perfect sense. I believe the issue with the documentation however, is that the graph does not show what metrics are sent to Lago to produce the resultant values.

For my example & initial implementation, I assumed that I was supposed to send the total storage used at any given point of time. IE that I sent 10 previously, and then sent 15, 20, and 5 as my metrics on the associated days, and that the example graph sent 1 previously, followed by 2,3, and then 1 during the window. It appears however, that to produce the graph, values of 1 previously, followed by 1, 1, and -2 would need to be sent. (and for my example, start with 10, then send 5, 5, and -20)

constructing the graphs

I can see how to construct the values used in the chart by sending deltas as mentioned above (both positive and negative values) however, I am very worried about two things in this case. 1: some users have files stored already. If they delete these files, they can have a negative metric as all of the negative deltas are sent. 2: If something ever happens to cause drift (IE a user deletes a file, but it errors and is not recorded) a user could end up charged for something incorrectly.

absolute values

A potential solution is the ability to send an "absolute" value (that is, stop using the sum of the values used so far and use that absolute value as the sum moving forward). As mentioned previously, this is supposedly supported using custom expressions (see this feature request) however I suspect that there was a miscommunication and the custom expressions only allow using the mathmatical absolute value operator (convert negatives to positives) and not actually setting the value that new sum (which is I believe what the user was asking for).

I believe given that, that issue above should be re-opened, and the documentation clarified to note that it is not currently possible to override the current sum used for the weighting calculations, and that to decrease the sum, a negative value must be sent.

I hope in the future the ability to send an absolute is added, as that would make weighted sums into one of the most powerful metrics, but that discussion belongs more on the feature requests page.