What Is hasTierBenefit Schema?

hasTierBenefit identifies a benefit category provided by a particular MemberProgramTier in a loyalty program.

The property expects TierBenefitEnumeration and is used on MemberProgramTier. Current enumeration members cover loyalty points, loyalty pricing, loyalty returns, and loyalty shipping.

The enumeration names a benefit category, not its complete commercial terms. Detailed prices, shipping conditions, return policies, and point-earning rules still need their own authoritative entities and checkout or account evidence.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Identify the real tier benefit.
• Choose the matching enumeration.
• Connect detailed policies.
• Test member and public outcomes.

Use the free backlink checker to identify linked program and product pages before changing a shared tier benefit.

Primary specification: Schema.org definition for hasTierBenefit.

hasTierBenefit is accurate when every declared category is backed by a real benefit available to members of that tier.

hasTierBenefit is used on MemberProgramTier and expects a TierBenefitEnumeration value.

It should not be placed directly on MemberProgram, Offer, PriceSpecification, ShippingService, MerchantReturnPolicy, or ProgramMembership. Those entities can define the program, operational benefits, or member state, but the benefit category belongs to the tier.

Keep the tier's stable @id and program relationship intact. Other policy entities can reference the tier through validForMemberTier, creating a graph from benefit category to the specific terms that implement it.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Resolve the canonical tier.
2. Attach the enumeration member.
3. Keep operational policies separate.
4. Join them through tier identity.

Review MemberProgramTier schema.

Correct placement keeps benefit classification on the tier while detailed prices, shipping, returns, and points remain in their proper entities.

TierBenefitLoyaltyPoints indicates that the tier provides a loyalty-points benefit, but it does not by itself define the earning amount, unit, multiplier, redemption value, or expiration rule.

Use membershipPointsEarned where a supported Number or QuantitativeValue accurately represents points earned, with unitText when the program uses miles, stars, or another named unit. Keep earning basis and ledger logic explicit.

Test eligible products, spend basis, taxes, discounts, refunds, cancellations, bonus periods, rounding, caps, and expiration. A points category without a working ledger benefit is a false promise.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Declare the points category.
• Define amount and unit where supported.
• Document earning basis.
• Compare loyalty ledger.

A loyalty-points benefit is truthful when the tier category and the actual points ledger produce the same earning outcome.

TierBenefitLoyaltyPrice indicates member-only or member-improved pricing for the tier, while the actual amount belongs in a tier-scoped PriceSpecification.

Use validForMemberTier on the member PriceSpecification and keep a truthful public price when nonmembers can purchase. Multiple tiers can share a specification when they receive the same amount; different amounts need separate specifications.

Currency, quantity, taxes, effective dates, product eligibility, promotions, and account status still control the price. The category alone never proves that every product receives a discount.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Declare the price benefit.
2. Create member price policies.
3. Preserve public baseline.
4. Test every tier and product cohort.

A loyalty-pricing benefit is accurate when each eligible tier receives the published amount and public shoppers retain the correct baseline.

TierBenefitLoyaltyShipping indicates a tier-level shipping benefit, while ShippingService, OfferShippingDetails, and ShippingConditions define the actual service, rate, timing, destination, and exclusions.

The benefit may be free standard shipping, a reduced rate, expedited handling, or another verified program term. Do not infer worldwide free shipping or free express delivery from the enumeration name.

Use validForMemberTier on the relevant ShippingService or shipping entity. Preserve public shipping alternatives and product, seller, destination, weight, dimension, and availability exceptions.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Declare the category.
• Build the exact shipping service.
• Attach eligible tiers.
• Keep public and exception policies.
• Test checkout.

Use validForMemberTier and ShippingService for detailed eligibility and shipping policy.

A loyalty-shipping benefit is truthful when the selected member service produces the same price, timing, and scope at checkout.

TierBenefitLoyaltyReturns indicates a return-policy benefit for the tier, while MerchantReturnPolicy contains the actual member terms.

A benefit can mean a longer window, waived return fee, additional method, or another operative advantage. The enumeration does not specify which term changes, and a shipping benefit does not automatically imply a return benefit.

Create a tier-scoped MerchantReturnPolicy only when customer support and legal policy use those terms. Keep the public return policy for nonmembers and test expired or downgraded accounts.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the operative return advantage.
2. Declare the category.
3. Build the detailed tier policy.
4. Test public and member returns.

A loyalty-returns benefit is accurate when the tier category points to terms that customer support actually honors.

A MemberProgramTier can carry multiple hasTierBenefit values when it genuinely provides multiple benefit categories.

A Gold tier may include loyalty points, member pricing, and member shipping while leaving returns unchanged. Each category should have a corresponding detailed policy or ledger behavior, and each policy should reference the same canonical tier identity.

Do not copy the union of all program benefits onto every tier. Build a matrix of tier versus benefit, then compare that matrix with enrollment pages, account dashboards, checkout, fulfillment, and returns operations.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Create the tier-benefit matrix.
• Attach only real categories.
• Join detailed policies.
• Test each tier independently.

Multiple benefits are well modeled when every tier lists exactly the categories its members receive and no others.

Common mistakes include using free text instead of TierBenefitEnumeration, attaching the property to the program, declaring benefits without operational policies, copying all benefits to every tier, using unstable tier IDs, and omitting public alternatives.

Other defects include stale benefits after a program change, shipping overreach, prices applied to nonmembers, returns not honored by support, points that disagree with the ledger, and syntax checks without account-state testing.

Repair the membership source and each benefit system together. Tier benefits affect product pages, checkout, loyalty accounts, shipping, and returns, so stage changes and retain cross-system regression cases.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Crawl every benefit declaration.
2. Validate parent and enumeration.
3. Join detailed policies.
4. Test account outcomes.
5. Repair shared sources.

Benefit lifecycle and stacking rules also need explicit tests. Record effective dates, enrollment grace periods, tier upgrades and downgrades, promotion precedence, coupon compatibility, and the behavior of carts containing both eligible and excluded products. When a temporary campaign improves an existing member benefit, keep the permanent tier category distinct from the campaign terms and verify the rollback state after expiration. This prevents an expired promotion from remaining embedded as if it were a permanent loyalty entitlement.

hasTierBenefit defects require category, tier identity, policy, entitlement, and live member evidence together.