In eCommerce and SaaS, many products are not difficult to understand because of pricing or availability, but because it is unclear who they are actually designed for. Is a product meant for beginners or experienced users? For individual consumers or businesses? For a global audience or a specific market?
The audience property in schema markup provides a way to make this intent explicit. By modeling the intended user group directly in structured data, you reduce ambiguity for search engines, feeds, and other systems that rely on machine-readable signals to interpret products and services.
This guide explains how to use the audience property correctly, with practical patterns and examples tailored to real-world eCommerce and SaaS implementations.
What is audience in schema markup?
Audience is used in schema markup to describe who a product, service, or piece of content is intended for. It allows you to explicitly model the intended user group rather than forcing that information to be inferred from product names, categories, or marketing copy.
In Schema.org, audience typically points to an Audience type or one of its more specific subtypes, such as PeopleAudience or BusinessAudience. These audience objects let you describe characteristics like age, gender, business context, geographical coverage, or conceptual segments such as skill level or profession.
Unlike product attributes (such as size, color, or price), the audience property does not describe the item itself. Instead, it describes intent and suitability—who the product was designed for and who can reasonably use it. This makes it especially useful for eCommerce and SaaS, where many offerings are ambiguous without additional context.
For example, two products may look similar on the surface but target very different users:
- A yoga mat for beginners vs one for advanced practitioners
- Software built for individual freelancers vs enterprise teams
- A toy intended for toddlers vs one for teenagers
The audience property helps make these distinctions explicit in structured data. While it does not guarantee rich results or rankings, it improves machine understanding, supports cleaner data reuse (feeds, assistants, internal search), and reduces ambiguity in large or complex catalogs.
Where can you use the audience schema?
A practical benefit of schema markup is improved clarity: by defining the intended audience directly, systems can better distinguish between similar products, services, or content that serve different users.
In practice, it is most valuable when the target user is not immediately obvious from the name or category alone.
Below are the most common and practical schema types where audience can be used, along with typical use cases.
1. Product
Product is the most common place to use audience in eCommerce. It helps clarify who a product is designed for when intent is ambiguous.
In most cases, the audience applies to all variants of a product and can be modeled at the ProductGroup level, with individual Product items handling size, color, or other SKU-specific attributes.
Common audience properties used with Product include:
- suggestedGender (using GenderType where applicable)
- Age-related properties (suggestedMinAge, suggestedMaxAge, or suggestedAge with QuantitativeValue)
- audienceType for concepts such as skill level, life stage, or pet type
- geographicArea when the product is designed for a specific market or region
These properties help distinguish products that may look similar but are intended for different users, such as beginner vs advanced equipment, children’s vs adult items, or region-specific products.
2. SoftwareApplication
For SaaS and digital products, audience is especially useful for clarifying who the software is built for, such as individual users, teams, or entire organizations. In B2B contexts, BusinessAudience is usually more appropriate than PeopleAudience.
When using SoftwareApplication schema, the BusinessAudience allows you to describe the type and scale of businesses the software is intended for, such as startups, small businesses, or enterprise organizations. This is particularly valuable for SaaS products that offer different plans, features, or onboarding experiences depending on company size or business context.
Common audience segment for SoftwareApplication include:
- Business vs consumer context
- Company size
- Team or functional role
- Skill or experience level
- Industry or niche focus
- Geographic or regulatory context
Example
{
"@type": "SoftwareApplication",
"name": "InvoicePro",
"audience": {
"@type": "BusinessAudience",
"audienceType": "Small businesses"
}
}3. Service
For services, the audience property helps clarify who the service is intended for, especially when the same type of service can apply to very different users, markets, or locations. This is particularly useful for professional, local, or specialized services where relevance depends on both niche and geography.
audienceType can be used to describe niche segments, such as industries, professions, or business types.
Using audience with a geographical focus allows you to describe intentional targeting, such as services designed for a specific country, region, or market with local regulations, language, or business practices in mind.
This differs from areaServed, which describes where a service is available or delivered, regardless of who it is designed for. A service can be technically available in many regions but intentionally designed for a specific market or niche. In those cases, audience captures relevance, while areaServed captures coverage.
Example
{
"@type": "Service",
"name": "SEO Consulting",
"audience": {
"@type": "BusinessAudience",
"audienceType": "Ecommerce companies"
}
}4. Course and Educational Offerings
Educational offerings often differ by skill level, age suitability, or professional background, and audience allows you to model these differences explicitly instead of relying only on course titles or descriptions like “Introduction” or “Advanced,” which can be interpreted inconsistently.
This is particularly useful for online courses, certifications, workshops, and training programs that serve very different learners under the same topic.
Common audience dimensions for educational content include:
- Skill or experience level (e.g. beginner vs advanced)
- Professional or industry focus
- Age suitability (especially for children’s education)
- Business vs individual learners
When courses are intended for organizations (for example, corporate training or team onboarding), BusinessAudience can be used to reflect that context more accurately than PeopleAudience.
Example
{
"@type": "Course",
"name": "Technical SEO for Beginners",
"audience": {
"@type": "PeopleAudience",
"audienceType": "Beginner"
}
}5. Event
Conferences, workshops, webinars, and meetups often cover similar topics but are designed for very different audiences, such as beginners, professionals, children, or business teams.
Using audience allows you to express key distinctions such as professional focus, experience level, or business context directly in structured data. This is particularly useful for recurring events, industry conferences, or educational workshops where the same theme may be tailored to different attendee groups.
Events may also target a specific market or niche. In these cases, audienceType can be used to describe the intended segment, while BusinessAudience is appropriate when the event is designed primarily for organizations rather than individuals.
Example
{
"@type": "Event",
"name": "TechSEO Conference",
"audience": {
"@type": "BusinessAudience",
"audienceType": ["Technical SEO professionals", “Developers”]
}
}6. CreativeWork (Books, Media, Content)
The CreativeWork type covers a wide range of content, including guides, books, reports, whitepapers, research, and long-form educational resources. In these cases, the audience property is useful when the content is explicitly written for a specific group, rather than for a general readership.
Creative works often share topics across very different audiences. For example, a guide about SEO could be written for beginners, content marketers, developers, or technical SEO specialists. Without an explicit audience definition, that intent must be inferred from titles or copy, which can be ambiguous. Using audience allows you to model the intended reader profile directly in structured data.
Example
{
"@type": "Book",
"name": "Introduction to Coding for Kids",
"audience": {
"@type": "PeopleAudience",
"suggestedMinAge": 7
}
}What can be defined using the audience property?
The audience property can be used to describe different aspects of who an offering is intended for. Below are the most common and practical ways to implement in your structured data.
1. Gender
Gender-based audience definitions should be used when a product is explicitly designed, fitted, or formulated for a specific gender. In schema markup, this is expressed using the suggestedGender property within a PeopleAudience.
The suggestedGender property communicates who the product is intended for, not who is allowed to use it. This distinction matters: gender targeting in structured data should reflect design intent, not marketing assumptions or restrictions.
When defining gender in structured data, Schema.org provides two GenderType enumeration, which should be referenced using its canonical URL values:
Although suggestedGender technically accepts plain strings, it can quickly become inconsistent at scale, as variations like “women”, “Female”, or abbreviations may be introduced across different pages or systems. That’s why I prefer referencing GenderType with the canonical URLs.
Example (women’s apparel product)
{
"@type": "Product",
"name": "High-Waist Training Leggings",
"audience": {
"@type": "PeopleAudience",
"suggestedGender": "female"
}
}2. Age
Age-based audience definitions are one of the clearest and least ambiguous uses of audience. They are particularly important for products where age suitability affects safety, usability, or expectations, such as toys, educational products, and books.
In Schema.org, age targeting for a PeopleAudience can be expressed using separate properties for required and suggested age limits, rather than a single combined range. This distinction allows you to clearly model whether an age threshold is mandatory or advisory.
requiredMinAgeandrequiredMaxAgeshould be used when an age limit is enforced (for example, legal restrictions or safety requirements).suggestedMinAgeandsuggestedMaxAgeshould be used when the age range reflects intended suitability, not enforcement.
Schema.org follows UN/CEFACT unit codes for age values. Commonly used units include:
- ANN for years
- MON for months
- DAY for days
Pro Tips:
PeopleAudience uses plain numeric integers in 4 age properties (suggestedMinAge, suggestedMaxAge, requiredMinAge, requiredMaxAge), and they typically represent age in years. When you need to be more precise,, suggestedAge can be used with a QuantitativeValue to model age as a range or with explicit units (such as months).
Example for a product suggested for ages 8–12
{
"@type": "Product",
"name": "Beginner Science Experiment Kit",
"audience": {
"@type": "PeopleAudience",
"suggestedMinAge": 8,
"suggestedMaxAge": 12
}
}Example for a product that is suitable for infants aged 3-12months
{
"@type": "Product",
"name": "Soft Sensory Play Mat for Infants",
"audience": {
"@type": "PeopleAudience",
"suggestedAge": {
"@type": "QuantitativeValue",
"minValue": 3,
"maxValue": 12,
"unitCode": "MON"
}
}
}3. Audience Type (audienceType)
The audienceType property is used to describe an audience in conceptual or categorical terms when gender or age alone is not sufficient. Rather than defining who the user is, it defines how the user relates to the product—through experience level, role, life stage, context, or needs.
In eCommerce and SaaS, audienceType is especially useful for modeling segments that are intent-driven rather than demographic. These are often the same labels used in navigation, filters, or internal taxonomy, such as “Beginner,” “Construction workers,” or “Small businesses.” Because audienceType is a free-text value, it should be treated as a controlled vocabulary, not an open-ended field.
Typical concepts that work well as audienceType include skill or experience level, life stage, professional role, usage context, accessibility needs, and non-human audiences such as pets. What matters most is that the value describes a stable, repeatable audience category, not a temporary marketing message.
Example (product targeting beginners)
{
"@type": "Product",
"name": "Beginner Yoga Mat",
"audience": {
"@type": "PeopleAudience",
"audienceType": "Beginner"
}
}Because audienceType is flexible, it should be used with restraint. If removing the value would not change who the product is suitable for, it likely does not belong in audience. When used consistently, however, audienceType becomes a powerful way to align structured data with real-world segmentation used across your store or platform.
4. Geography
Geographical audience definitions are used when a product, service, or offering is intended for users in a specific location or region, not merely sold or shipped there. This distinction is important: availability and shipping are modeled elsewhere in schema, while geographical audience describes intended relevance or suitability.
In Schema.org, geographic targeting is expressed using the geographicArea property within an Audience. This property allows you to reference a country, region, city, or broader area using a place-based type such as AdministrativeArea or Country. It is particularly useful for region-specific products, localized services, regulatory-bound offerings, or SaaS tools designed for certain markets.
Geographical audience should not be used to replicate shipping rules or fulfillment logic. Instead, it should reflect cases where the product itself is designed, localized, or compliant for a particular geography, such as language-specific editions, regionally regulated products, or software built for a specific market.
Example (product intended for the Hong Kong market)
{
"@type": "Product",
"name": "Traditional Chinese SEO Guide",
"audience": {
"@type": "Audience",
"geographicArea": {
"@type": "Country",
"name": "Hong Kong"
}
}
}When used correctly, geographicArea helps distinguish between global products and those with intentional regional focus. This is especially relevant for SaaS platforms with market-specific features, compliance requirements, or localized workflows.
5. Business Audience
When a product or service is intended for organizations rather than individual consumers, the audience should be modeled using BusinessAudience. This is especially relevant for SaaS platforms, enterprise tools, B2B services, APIs, and subscription-based software where the buyer, user, or decision-maker is a company.
BusinessAudience allows you to describe the type and scale of businesses the offering is designed for, rather than relying on people-based demographics. This makes it possible to distinguish consumer-facing software from tools built specifically for startups, small businesses, or large enterprises, even when the product name alone does not make that clear.
Common dimensions that can be expressed with BusinessAudience include company size, organizational maturity, or functional teams. These audience definitions are often already present in sales pages, pricing tiers, and go-to-market messaging, which makes them a natural fit for structured data.
Example (SaaS product for small businesses)
{
"@type": "SoftwareApplication",
"name": "InvoicePro",
"audience": {
"@type": "BusinessAudience",
"audienceType": "Small businesses",
"numberOfEmployees": {
"@type": "QuantitativeValue",
"minValue": 5,
"maxValue": 50
}
}
}In this example, the audience definition communicates that the software is intended for organizations of a certain size, rather than individual users. This distinction is particularly useful for platforms that offer different plans or feature sets based on business scale.
Best practices for using audience in Schema Markup
Using the audience property effectively is less about adding more data and more about modeling intent clearly and consistently. The following best practices help ensure your audience definitions remain accurate, scalable, and useful across eCommerce and SaaS implementations.
1. Use audience only when it adds real clarity
Not every product needs an explicit audience definition. Add audience only when removing it would make the product’s intended user less clear. If the audience can already be inferred reliably from the product name or category, adding audience markup may provide little additional value.
This is especially important for large catalogs, where unnecessary audience definitions can introduce noise rather than clarity.
2. Prefer intent over marketing language
Audience definitions should describe who the product is designed for, not how it is being promoted at a given moment. In structured data, audience is meant to capture stable suitability and intent, not campaign-driven or performance-driven labels.
Marketing terms such as “Best seller,” “Trending,” “Limited edition,” or “Holiday special” may be useful for conversion, but they do not describe an audience. These labels change frequently and do not alter who the product is actually suitable for.
When choosing audience values, focus on characteristics that would remain true even if all marketing copy were removed. Ask whether the value explains who can reasonably use the product rather than why the product is currently being highlighted.
For example, “Beginner” is a valid audience because it describes user capability. “Popular with beginners” is not, because it describes performance, not intent.
When in doubt, ask whether the value describes who the product is for rather than how the product is being sold.
3. Use the most specific audience type available
When modeling audiences, choose the most appropriate subtype:
- Use PeopleAudience for individual consumers
- Use BusinessAudience for organizations and B2B use cases
This distinction helps crawlers understand whether the product is meant for personal use or organizational adoption, which is especially important for SaaS and subscription-based offerings.
4. Treat audienceType as a controlled vocabulary
Because audienceType accepts free-text values, it should never be treated as an open field. Instead, define a small, controlled set of allowed values and reuse them consistently across your site.
For example, decide whether you will use:
- “Beginner” vs “Entry level”
- “Small businesses” vs “SMBs”
- “Professionals” vs “Experts”
Once defined, enforce these values in your CMS, feeds, or schema generators. This improves consistency, simplifies validation, and prevents audience fragmentation across large catalogs.
5. Separate audience from variants and attributes
One of the most common mistakes when using the audience property is using it to model product variants or physical attributes. Audience describes who the product is suitable for, while variants and attributes describe what version of the product is being sold.
Product attributes such as size, color, material, capacity, or storage are characteristics of the item itself and should be modeled on the Product, Offer, or variant-level schema.
Audience, by contrast, should remain stable across variants. A product does not suddenly target a different audience because it is available in a different size or color.
When working with variant-heavy catalogs, audience is often best applied at the ProductGroup level, where it can describe the intended users for all variants collectively. This avoids duplication and ensures consistency when multiple SKUs share the same audience but differ in attributes like size or color.
For example, a children’s helmet available in multiple sizes should not encode size in audience. Instead, the ProductGroup can define the intended audience (kids, specific age range), while each Product variant handles its own sizing.
6. Use suggested vs required properties Intentionally
Age limits are not always the same. Some products are designed with a recommended age range in mind, while others must enforce a minimum or maximum age for safety or legal reasons.
Schema markup lets you reflect this difference by separating suggested age guidance from required age restrictions, so it’s clear when an age limit is flexible and when it must be followed.
When defining age or other thresholds, distinguish clearly between guidance and mandatory:
- Use
suggestedMinAge/suggestedMaxAgefor general suitability - Use
requiredMinAge/requiredMaxAgeonly for mandatory restrictions
A good way to understand this difference is through movies.
A family-friendly movie may be recommended for a certain age group, but younger viewers could still watch it with parental guidance. In this case, the age is advisory and should be modeled using suggested age properties.
By contrast, a movie like Deadpool has a legally enforced age restriction in many regions. Viewers below the minimum age are not allowed to attend, regardless of context. This is a required age boundary and should be modeled using required age properties.
7. Keep audience definitions stable over time
Audience definitions should be relatively stable, not tied to seasonal campaigns or temporary positioning. If an audience label changes frequently, it likely belongs in marketing copy, not structured data.
Stable audience modeling makes schema easier to maintain and more reliable for reuse in feeds, search, and internal systems.
8. Validate for logical consistency
Finally, ensure your audience definitions make sense in context. For example:
- Kids audience paired with adult-only products
- BusinessAudience applied to consumer apps
- Geographical audience that contradicts localization
Simple QA checks like these prevent subtle but impactful data quality issues.
Conclusion
The audience property helps clarify who a product or service is designed for, how it differs from similar offerings, and where it fits within a broader catalog or platform.
By focusing on stable audience characteristics such as age, gender, business context, geography, and user type, you create structured data that is clearer, more consistent, and easier to scale.
Start with products or services where intent is genuinely ambiguous, apply the audience deliberately, and treat it as part of a long-term data modeling strategy rather than a one-off optimization.
