[Proposal] Handling Pricing Models that Use a Non Direct to Currency Pricing Model

[rileyjenk]

Type

Metric Normalized? Yes

Description

Numerous vendors pricing model do not have direct path to currency for pricing, but rather have an intermediary unit that is purchased (credits, tokens, points...etc). These units then have a unit:currency ratio that is purchased by the customer. This sort of model requires both an understanding of balances of units purchased, their consumption, and the appropriate conversion to a currency. Often, these pricing models include infrequent invoicing, such as a single invoice at front and later invoices in the case of overage.

It is not enough to use ConsumedUnit and ConsumedQuantity because the use case of being able to track how many compute ours, rows, data size, network bytes still applies to these pricing models. Users also need to understand the number of non currency units and the currency cost of each line item.

In order for vendors with such a pricing model, to provide granular usage data, outside of single entries for the purchase of these units, FOCUS should include a construct for these vendors to provide real currency detail (BilledCost) that matches invoice records, ], the usage of their chosen non currency unit and that usages EffectiveCost considering their conversion logic to currency.

Definition of done

• [ ] Rationalize vendor-neutral, cross-cloud naming
• [ ] Complete spec template and include naming (code name, display name), constraints, guidelines, compatibility with major providers etc. If Normalized Dimension
• [ ] Include principles and governance criteria for maintaining this dimension

If Normalized Dimension Work for generating the normalized list of supported values is tracked in a separate issue. Mappings between normalized values and vendor specified values need to be explored as a part of this work. However, these mappings are not included in the spec documentation. Separate tasks will be created for making these mappings available to practitioners outside of the FOCUS repository.

[udam-f2]

@rileyjenk Can you elaborate on why this can't be accomplished today?

If the provider gives a charge record for the up-front payment: (billed cost $N, effective cost: $0)

and then periodic records for the burn-down: (billed cost $0, effective cost: $K)

Does that cover this case? Or are you saying we should not expect the burn-down records to be in a currency?

Seems like if we want 'cost and usage' data, the usage has to be converted to a 'cost' record or we're losing a lot of value. I dealt with several of these providers in the past but always found a way to convert the 'usage' to 'cost' because ultimately, they have to burn-down what you paid up-front anyway.

[udam-f2]

Also, if you're proposing a different approach, will current semantics in v1.0 be backward incompatible?

[rileyjenk]

The problem occurs when the vendor doesn't have a direct currency conversion. Some have a scenario where they charge over an allocated limit. Sometimes it is simply that they have a non currency unit that the customer purchase. For example many AI platforms, where you purchase tokens, or a SAAS vendor like snowflake where the customer purchases credits. The practitioner has to balance both variables, the number of tokens/points/credits and the ratio of those credits to dollars. If the spec doesn't allow for the inclusion of non currency units, the practitioner is essentially blind to one of the largest attributes of their agreement with that vendor.

This is complicated by the fact that if a customer is given resources at different rates it is left to the practitioner to determine the conversion of the unit to the $ amount. By providing the number of non currency units the practitioner isn't forced to do the calculation. This is especially true if their is a graduated/sliding scale of unit to $ ratio or other options that affect the conversion.

[udam-f2]

To be clear though, Snowflake and many AI platforms do have a conversion rate for their offerings. Your suggestion if I understand correctly - rather than just convert the usage amount into $s directly, provide additional columns that can keep the non-currency unit price and conversion rate in the data.

If you use Snowflake credits: your warehouse costs 2 credits/hr, credits are 6$/credit and you use an hour, you should see: pricing quantity: 1 pricing unit: hour list unit price: 12 list cost: 12 billing currency: USD -- possible additions -- non-currency unit type: credits/hour non-currency list unit price: 2 non-currency unit rate: 6

Seems like this can safely come after v1.0 without any backward compatibility issues?

[flanakin]

I'd love to hear what practitioners would prefer to see here.

[jpradocueva]

Classified as Pricing & P2 by Maintainers on May 24 call.

[rileyjenk]

@jpradocueva this is the issue I created to address vendors that do not have a direct to currency pricing model.

[jpradocueva]

@rileyjenk, the issue is currently marked as priority 2 and does not appear on the revised priority list for Release v1.1. Would you recommend any changes, or should we maintain the current status?

[shawnalpay]

@rileyjenk I'm marking this one as 1.2 consideration, as I believe it will be a part of #616. Do you think we will need a separate Work Item for this issue, or can/should we close it? Let's discuss in a call soon.

[shawnalpay]

Discussed this in Oct 28 Maintainers. Will keep open under the umbrella of #616.

[jpradocueva]

Comments from Members' call on Oct 31:

Analysis: Addressing pricing models within the FOCUS specification. Issue overlaps with SaaS pricing models discussion and is not directly in 1.2 scope. Agreements: Keep #337 open, with a clear note that it will be included in future discussions on pricing models.