APP-1935 Show image/general data storage costs on invoice #462
Conversation
ehhong
changed the title
ehhong
changed the title
ehhong
changed the title
proto/viam/app/v1/billing.proto
Outdated
| @@ -71,6 +71,8 @@ message GetCurrentMonthUsageResponse { | |||
| double discount_amount = 8; | |||
| double total_usage_with_discount = 9; | |||
| double total_usage_without_discount = 10; | |||
| double image_data_cloud_storage_usage_cost = 11; | |||
There was a problem hiding this comment.
Its unclear to me what this means from reading these fields. Is this tabular/binary separation?
There was a problem hiding this comment.
yes-ish. we decided to use the language used on our pricing page. it's not juust tabular because it includes tabular data not used for data/ML. basically, general = tabular + packages + history + logs
There was a problem hiding this comment.
Aren't we breaking down all the usage costs into their own types? can't we just add a 1:1 mapping for that? Otherwise it just seems unclear?
There was a problem hiding this comment.
we are on the backend, but the designs show an image/general split. I want to avoid doing calculations on the frontend, but if we think we will just display all categories in the future, I'd consider adding a 1:1 mapping. that's a product q though
There was a problem hiding this comment.
one thing to consider: we are moving from "cloud storage" --> "data management" in our copy. do we want that change to be reflected in this proto? our backend models are all called "cloud storage"
There was a problem hiding this comment.
yeah, then Im not sure how else we could it apart from this way :)
There was a problem hiding this comment.
i don't really want to include the full breakdown because i think it's early optimizing, we don't even know if the full breakdown is stable
i would say the same thing for the image vs non image. at least by having the breakdown, we are giving ourselves the flexibility to change what goes into which category later. if we had broken down what goes into cloud storage earlier, we wouldnt even have to make this API change in the first place. i dont think i'm gonna be convinced the other way but we can agree to disagree if its 2 to 1.
There was a problem hiding this comment.
For early optimization the more granular break down makes sense for sure. That being said, we don't want to show the breakdown to users. I'm not sure I am sure what the middle ground here is but I think this going to be somewhat of a product decision? if the latter is definitely not then I think that we have to have more generalized names?
There was a problem hiding this comment.
thanks guys for the input. I'm now convinced that the granular categories would be better (if we can publish them), otherwise we'll have to do image/general. I'm tracking down some ops / GTM people right now, will let you know when I have an update!
There was a problem hiding this comment.
okay, discussed offline: decided on two subcategories:
double binary_data_cloud_storage_usage_cost = 12;
double other_cloud_storage_usage_cost = 13;
I think it actually requires a scope :( All public API changes do. It can be super quick and short one. |
@michaellee1019 Julia asked Steve what we should do in this situation, Steve said sending a quick email to stakeholders (Eliot, Natalia, Emily, Devin) was sufficient. I just sent an email out about this change |
Excellent, sounds good! |
ehhong
force-pushed
the
APP-1935
branch
2 times, most recently
from
f0c3f30 to
c32877c
Compare
ehhong
added
the
ready-for-protos
ehhong
removed
the
ready-for-protos
Include breakdown of image and general (non image) data storage costs on invoice and other billing surfaces (epic) (designs)