This doc explains required styles and recommended phrasings for pricing-related requirements.
Explanations of philosophy
If you haven't already, please read Overview of pricing model to understand our two different pricing models. Understanding that we have two different pricing models is an important first step of understanding our guidelines around pricing-related language.
These are the primary places in our public docs where pricing- and billing-related impacts are documented:
- We explain billing impacts in the main pricing and billing-related docs. The main docs in this area are:
- When a feature requires a specific pricing edition, we include that in the requirements of the doc for that feature. But because there are only a few capabilities limited by the Pro and Enterprise editions, you won't see many of these callouts.
- User type (basic, core, and full platform): information about how features are restricted based on user type is located in the user type doc. For more about style and formatting related to user types, see User-related style guidelines.
- Our license docs (such as this one): these docs are primarily written by legal- and agreement-focused teams, not the docs team.
Guidelines for features that may result in high data generation
Some New Relic tools and features can result in high levels of data ingest and, if a customer is on the usage-based pricing model, higher billing. Here are some guidelines about these situations:
- For the usage-based pricing model, data ingest is a major billing factor, so almost all customers will be aware of the need to keep an eye on their usage and attempt to understand data ingest impacts when adding new monitoring solutions or adjusting configuration. Because there are many ways our tools and various configurations might result in higher-than-expected data ingest, we should generally only mention this as a concern in the docs in these situations:
- When we've changed something and that change has a good chance of resulting in an unexpected data ingest spike: if we document such an impact, we should treat that addition as temporary (for example, removing the note after several months).
- When it's known that there can be a fairly common way of setting up one of our tools that is especially likely to result in high data ingest: in that case, we can recommend a solution for avoiding that.
- If we think we should document a risk of high data ingest, focus on the increase in data ingest, not on the billing impacts. This is for two reasons:
- Billing impacts are only a factor for customers on our usage-based pricing model; we still have customers on the original pricing model, where data ingest is not a billing factor.
- For customers on our usage-based pricing model, most should understand that data ingest is a billing factor.
Style and formatting
Some notes on style and formatting for pricing-related language:
- Pricing models:
- Use the word "model" to refer to our two pricing models: the usage-based pricing model, and our original pricing model.
- Examples of referring to models:
- If you're on our usage-based pricing model...
- If you're on our original pricing model...
- When referencing a model, it's good practice to point to either the doc for that model, or else the doc explaining the differences between the models, whichever makes more sense.
- "usage-based." Our newer pricing model can be referred to as “usage-based” or “consumption-based,” but “usage-based” is the most commonly used and more preferred term.
- Editions:
- Our pricing editions are not "plans" or "models" or "tiers"; they are "editions." One exception is that it's acceptable to refer to the Free edition as the "free tier" simply because we have used that in the past.
- Our pricing editions are formatted with title case: Free, Standard, Pro, and Enterprise. Example use: If your organization is on the Pro edition...
- A New Relic organization can have only a single edition.
- Avoid referring to users by their edition (e.g., your Pro users or Enterprise users). The cost of billable users does differ depending on edition, but we should attempt to keep these two dimensions separate. Example wording: an organization with Pro edition and 10 full platform users.
- For recommendations for how to mention the edition in feature requirements docs, see edition guidelines.
- Billable users. For how to reference user type, see User-related language guidelines.
Exception for agreement- and contract-related language
Our license docs (like this one) use a different style and formatting than what we recommend above. Those docs are more legal/agreement-oriented. One different is that they use title case (for example, the Usage Plan) to reference agreement/contract terms they have specifically defined.
Recommendations for referencing edition in requirements
When you document a pricing edition-related restriction, use the following approach:
- Requirements section: When documenting features that require the Pro or Enterprise edition, add edition requirements in a "requirements" section of the doc, with wording like: "This requires a Pro or Enterprise edition." Only add pricing-related wording for the specific features that Pro and Enterprise edition give access to; this is a fairly small set of features.
- Pricing requirements in one section: As a general rule, attempt to place any pricing edition requirement in a single location and avoid putting it in multiple paragraphs.
- Original pricing model: At this point, only add edition-related requirements for our usage-based model editions, not original pricing model editions. The original pricing model will be more and more de-emphasized over time, as more customers get on the new pricing model, so there shouldn't be much need to mention original pricing aspects or edit those docs.