Modeling good practices

Use defensive pricing techniques

When it comes to modelling in Pricing2Yaml you are going to have several NUMERIC usage limits linked to BOOLEAN features. You should be carefull when setting their defaultValue as it can affect the feature evaluation.

Terminology

• A feature is considered enabled if its defaultValue is true
• A feature is disabled if its defaultValue is false
• An usage limit is enabled if its defaultValue is greater than 0
• An usage limit is disabled if its defaultValue is 0

TLDR:

• If a usage limit is linked to only one feature both should be enabled or disabled.
• An usage limit linked to multiple feature does not follow this rule.

Example

Good practice:

features:
  featureA:
    valueType: BOOLEAN
    defaultValue: false
  featureB:
    valueType: BOOLEAN
    defaultValue: true
usageLimits:
  featureALimit:
    valueType: NUMERIC
    defaultValue: 0
    linkedFeatures:
    - featureA
  featureBLimit:
    valueType: NUMERIC
    defaultValue: 30
    linkedFeatures:
    - featureB

Bad practice:

features:
  featureA:
    valueType: BOOLEAN
    defaultValue: false
  featureB:
    valueType: BOOLEAN
    defaultValue: true
usageLimits:
  featureALimit:
    valueType: NUMERIC
    defaultValue: 30
    linkedFeatures:
    - featureA
  featureBLimit:
    valueType: NUMERIC
    defaultValue: 0
    linkedFeatures:
    - featureB

Feature and usage limit inconsistencies

When it comes to modelling the following inconsistencies can happen:

• A feature is enabled and its linked usage limit is disabled
• A feature is disabled and its linked usage limit is disabled

Feature is enabled and usage limit is disabled

features:
  featureA:
    valueType: BOOLEAN
    defaultValue: true
usageLimits:
  featureALimit:
    valueType: NUMERIC
    defaultValue: 0
    linkedFeatures:
    - featureA

Feature is disabled and usage limit is enabled

features:
  featureB:
    valueType: BOOLEAN
    defaultValue: false
usageLimits:
  featureBLimit:
    valueType: NUMERIC
    defaultValue: 30
    linkedFeatures:
    - featureB

A story about bad modelling

The business ACME has a SaaS and they are planning to release an extra feature that enable users to store files in the cloud. They have stablished the following usage restrictions:

	Free	Professional	Enterprise
Data Storage	Not Included	50 GB	200 GB

ACME is using Pricing2Yaml to model his pricing and they have included the file storage feature like the following:

features:
  # other features
  fileStorage:
    description: Keep your files securely stored, up to date, and accessible across devices
    valueType: BOOLEAN
    defaultValue: false
    expression: userContext['currStorage'] < planContext['usageLimits']['dataStorageLimit']
usageLimits:
  fileStorageLimit:
    valueType: NUMERIC
    defaultValue: 50
    unit: GB
    linkedFeatures:
    - fileStorage
plans:
  FREE:
    features: null
    usageLimits: null
  PROFESSIONAL:
    features:
      fileStorage:
        value: true
    usageLimits: null
  ENTERPRISE:
    features:
      fileStorage:
        value: true
    usageLimits:
      fileStorageLimit:
        value: 200

As explained in the Pricing2Yaml syntax section all plans will inherit global features and usage limits defaultValue resulting in the following interpreted values when parsing the config file:

	Free	Professional	Enterprise
fileStorage	false	true	true
fileStorageLimit	50	50	200

The feature looks promissing and ACME decides to ship the feature. Months later, they decide to enable file storage feature to FREE users after doing some analysis on their data.

The developer in charge of mantaining the configuration file enables the file storge feature globally, but forgets to update global file storage limit.

Here is the config file with the modification:

features:
  fileStorage:
    description: Keep your files securely stored, up to date, and accessible across devices
    valueType: BOOLEAN
    defaultValue: true
    expression: userContext['currStorage'] < planContext['usageLimits']['dataStorageLimit']
usageLimits:
  fileStorageLimit:
    valueType: NUMERIC
    defaultValue: 50
    unit: GB
    linkedFeatures:
    - fileStorage
plans:
  FREE:
    features: null
    usageLimits: null
  PROFESSIONAL:
    usageLimits: null
  ENTERPRISE:
    usageLimits:
      fileStorageLimit:
        value: 200

Plans will inherit the following values from the configuration file:

	Free	Professional	Enterprise
fileStorage	true	true	true
fileStorageLimit	50	50	200

A week later the development team finds out that FREE users were storing an unusual amount of files and servers run out of disk space quickly. They tracked what went wrong and discover that fileStorageLimit was too high, so they change it accordinly.

features:
  fileStorage:
    description: Keep your files securely stored, up to date, and accessible across devices
    valueType: BOOLEAN
    defaultValue: true
    expression: userContext['currStorage'] < planContext['usageLimits']['dataStorageLimit']
usageLimits:
  fileStorageLimit:
    valueType: NUMERIC
    defaultValue: 5
    unit: GB
    linkedFeatures:
    - fileStorage
plans:
  FREE:
    features: null
    usageLimits: null
  PROFESSIONAL:
    usageLimits:
      fileStorageLimit:
        value: 50
  ENTERPRISE:
    usageLimits:
      fileStorageLimit:
        value: 200

Plans will inherit the following values from the configuration file:

	Free	Professional	Enterprise
fileStorage	true	true	true
fileStorageLimit	5	50	200

If they originally modeled the pricing with an usage limit of 0 GB, FREE users would not be able to store any file after enabling fileStorage globally and servers would not run out of space:

features:
  # other features
  fileStorage:
    description: Keep your files securely stored, up to date, and accessible across devices
    valueType: BOOLEAN
    defaultValue: false
    expression: userContext['currStorage'] < planContext['usageLimits']['dataStorageLimit']
usageLimits:
  fileStorageLimit:
    valueType: NUMERIC
    defaultValue: 0
    unit: GB
    linkedFeatures:
    - fileStorage
plans:
  FREE:
    features: null
    usageLimits: null
  PROFESSIONAL:
    features:
      fileStorage:
        value: true
    usageLimits:
      fileStorageLimit:
        value: 50
  ENTERPRISE:
    features:
      fileStorage:
        value: true
    usageLimits:
      fileStorageLimit:
        value: 200

Tag your features

If your pricing has a lot of features your potential users might have trouble to mentally process them all at once. This could lead the user to leave your page and choose another competitor due to the lack of structure of the pricing.

To information saturatin group related features with tags. Your users will see the features grouped by chunks small amounts, making the pricing easier to recall. This technique is known in psychology as chunking.

Here are some SaaS providers using this technique:

Mailchimp:

Salesforce:

Slack:

Example

Good practice:

syntaxVersion: '2.1'
saasName: Databox
url: https://web.archive.org/web/20250304080336/https://databox.com/pricing
tags:
- Data Collection
- Connect any Data Source
- Account management & security
features:
  dataSources:
    tag: Data Collection
  dataSyncFrequency:
    tag: Data Collection
  historicalData:
    tag: Data Collection
  warehouseDataStorage:
    tag: Data Collection
  databoxIntegrations:
    tag: Connect any Data Source
  thirdPartyIntegrations:
    tag: Connect any Data Source
    integrationType: MARKETPLACE
  pushCustomDataToAPI:
    tag: Connect any Data Source
  customApiIntegrations:
    tag: Connect any Data Source
  sqlIntegrations:
    tag: Connect any Data Source
  spreadsheetsIntegration:
    tag: Connect any Data Source
  userManagement:
    type: Account management & security
  twoFactorAuthentication:
    tag: Account management & security
  singleSignOn:
    tag: Account management & security
  advancedSecurityManagement:
    tag: Account management & security

Bad practice

syntaxVersion: '2.1'
saasName: Databox
url: https://web.archive.org/web/20250304080336/https://databox.com/pricing
features:
  dataSources:
  dataSyncFrequency:
  historicalData:
  warehouseDataStorage:
  databoxIntegrations:
  thirdPartyIntegrations:
  pushCustomDataToAPI:
  customApiIntegrations:
  sqlIntegrations:
  spreadsheetsIntegration:
  userManagement:
  twoFactorAuthentication:
  singleSignOn:
  advancedSecurityManagement:
   ## ..

Use usage limits naming conventions

It is a good habit to name usage limits including part of the feature name that is linked, for example:

• <featureName>Limit
• <featureName>Uses
• <featureName>Cap

Example

Good practice:

features:
  workspaces:
    valueType: BOOLEAN
    defaultValue: true
usageLimits:
  workspacesLimit:
    description: The number of workspaces you can use.
    valueType: NUMERIC
    defaultValue: 1
    unit: workspace
    type: NON_RENEWABLE
    linkedFeatures:
    - workspaces

Bad practice:

features:
  workspaces:
    valueType: BOOLEAN
    defaultValue: true
usageLimits:
  usageLimitWk:
    description: The number of workspaces you can use.
    valueType: NUMERIC
    defaultValue: 1
    unit: workspace
    type: NON_RENEWABLE
    linkedFeatures:
    - workspaces

Provide descriptions

When modeling features, we tend to reduce the length of the name by identifying it with a few keywords. However, understanding the functionality only looking at the name can be a difficult task and subject to interpretation.

In cases where further context is greatly appreciated, write a brief summary of the description in the description field. That way, users will be able to understand your feature even better. As always, decide when it is necessary to provide a little more context.

Example

Here is an example extracted from Databox:

Good practice:

features:
  dataCalculations:
    description: | 
      Easily calculate (add, subtract, multiply, divide) new metrics
      from any Data Source using Data Calculations.
    valueType: BOOLEAN
    defaultValue: true
    type: DOMAIN

Bad practice:

features:
  dataCalculations:
    # What calculation are performed?
    valueType: BOOLEAN
    defaultValue: true
    type: DOMAIN

Avoid using TEXT valueType

In 99.9% of total cases a pricing can be modeled with BOOLEAN features and NUMERIC usage limits, but when BOOLEAN and NUMERIC valueType are not enough you can use TEXT as a last resource. You should use BOOLEAN and NUMERIC as much as possible.

Example

Take a look at Search engine indexing (SEO) feature in Notion pricing:

You could be tempted to model this as a TEXT feature, but there is another option that uses BOOLEAN features. In this case we can model this feature as two BOOLEAN features, basicSearchEngineIndexing and advancedSearchEngineIndexing. basicSearchEngineIndexing is available for all plans and advancedSearchEngineIndexing is only available for Plus, Business and Enterprise plans.

Good practice:

features:
  basicSearchEngineIndexing:
    valueType: BOOLEAN
    defaultValue: true
  advancedSearchEngineIndexing:
    valueType: BOOLEAN
    defaultValue: false
plans:
  FREE:
    features: null
  PLUS:
    features:
      advancedSearchEngineIndexing:
        value: true
  BUSINESS:
    features:
      advancedSearchEngineIndexing:
        value: true
  ENTERPRISE:
    features:
      advancedSearchEngineIndexing:
        value: true

Bad practice

features:
  searchEngineIndexing:
    valueType: TEXT
    defaultValue: Basic
plans:
  FREE:
    features: null
  PLUS:
    features:
      advancedSearchEngineIndexing:
        value: Advanced
  BUSINESS:
    features:
      advancedSearchEngineIndexing:
        value: Advanced
  ENTERPRISE:
    features:
      advancedSearchEngineIndexing:
        value: Advanced

Avoid modelling trials

You might be tempted to model trial features or demos but in reality those features are not granting users permanent access. In practice if a feature is available for trial or a preview of it, that feature should not be enabled for that particular plan.

Example from Notion pricing:

Example

Example from Mailchimp:

Good practice:

Customer Journey Builder has a free preview for Free plan, that feature is false by default even if the pricing offers a preview.

features:
  customerJourneyBuilder:
    valueType: BOOLEAN
    defaultValue: false
plans:
  FREE:
    features: null
  ESSENTIALS:
    features:
      customerJourneyBuilder:
        value: true
  STANDARD:
    features:
      customerJourneyBuilder:
        value: true
  PREMIUM:
    features:
      customerJourneyBuilder:
        value: true

Bad practice:

Here security alerts is enabled for all plans permanently, but we only want FREE users to use it temporarily. Disabling that feature is highly recommended.

features:
  customerJourneyBuilder:
    valueType: BOOLEAN
    defaultValue: true
plans:
  FREE:
    features: null
  ESSENTIALS:
    features: null
  STANDARD:
    features: null
  PREMIUM:
    features: null

Avoid modelling recommended usage limits

Saas providers instead of restricting a feature for a particular plan, they make a suggestion for the ideal usage limit. These recommended users limit must not be modeled since there is no restriction for that feature.

Example extracted from Crowdcast pricing:

Example

	Free	Professional	Enterprise
Online text editor experience	Ideal for 1-3 concurrent users	Ideal for 5+ concurrent users	Ideal for 15+ concurrent users

Good practice:

features:
  onlineTextEditor:
    valueType: BOOLEAN
    defaultValue: true
plans:
  FREE:
  PROFESSIONAL:
  ENTERPRISE:
    # .. Not modeled recommended usage limits present

Bad practice:

You should not model recommended usage limits

features:
  onlineTextEditor:
    valueType: BOOLEAN
    defaultValue: true
usageLimits:
  onlineTextEditorConcurrentUsersPreference:
    valueType: TEXT
    defaultValue: Ideal for 1-3 concurrent users
    linkedFeatures:
    - onlineTextEditor
plans:
  FREE:
  PROFESSIONAL:
    usageLimits:
      onlineTextEditorConcurrentUsersPreference:
        value: Ideal for 5+ concurrent users
  ENTERPRISE:
    usageLimits:
      value: Ideal for 15+ concurrent users