[Proposal] SKU tier

[flanakin]

Type

Dimension: SkuTier or SkuPricingTier Normalized: No

Description

Add an ability to identify which tier is being used. 1.0-preview does not have any way to identify tiered pricing. All tiered pricing should be easily identifiable (e.g., PricingSubcategory = Tiered) and offer the ability to separate each tier (e.g., SkuTier = "\".

Definition of done

• [x] Rationalize vendor-neutral, cross-cloud naming
• [x] Complete spec template and include naming (code name, display name), constraints, guidelines, compatibility with major providers etc.

Want this column in FOCUS 1.0 GA?

Give it a 👍 below ↴

If you can discuss and help finalize the change, add yourself as an assignee ↗

Comments are welcome and encouraged!

[mike-finopsorg]

Would you need a SkuTier if the SKUPricingId pointed towards the price that was charged?

[marc-perreaut]

Identifying pricing tiers is useful to understand the pricing structure and threshold effects. Maybe SkuPricingTier is more explicit than SkuTier, as the pricing of the SKU is tiered, not the SKU itself.

[ijurica]

Next to SkuPricingTier we might consider introducing a PricingModel / PricingStrategy / PricingApproach column to indicate the pricing approach. Here are some of the available values:

• tier-based pricing
• volume-based pricing
• stairstep-based pricing
• per-unit pricing

[flanakin]

Would you need a SkuTier if the SKUPricingId pointed towards the price that was charged?

The finance team would because they don't have the ability to join these two extremely large datasets. If FOCUS is intended to be approachable and usable by anyone to answer questions about tiered pricing, then it would need to be in this dataset. I suppose the question is whether or not getting cost per specific tier is one of those scenarios.

Next to SkuPricingTier we might consider introducing a PricingModel / PricingStrategy / PricingApproach column to indicate the pricing approach.

This is covered by PricingSubcategory 🙂