What Is validForMemberTier Schema?

validForMemberTier identifies the MemberProgramTier or tiers for which an Offer, price, shipping policy, shipping service, or return policy is valid.

Its expected value is MemberProgramTier. The property can scope member-only pricing, free or discounted shipping, special Offer access, and return benefits without making those benefits appear universal.

The term is in Schema.org's new area, so vocabulary validity, target-consumer support, and live entitlement behavior should be tested separately. A tier reference is accurate only when the same account state receives the benefit at checkout.

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.

• Define the real benefit.
• Identify eligible tiers.
• Use stable tier entities.
• Test public and member outcomes.

Use the free backlink checker to identify linked landing pages before changing a shared member benefit.

Primary specification: Schema.org definition for validForMemberTier.

validForMemberTier is correct when every referenced tier receives the benefit and every noneligible shopper receives the proper public alternative.

validForMemberTier can be used on Offer, PriceSpecification, OfferShippingDetails, ShippingService, and MerchantReturnPolicy.

Choose the narrowest parent that owns the benefit. A member price belongs on the applicable PriceSpecification, a member shipping option can belong on ShippingService or shipping details, and return terms belong on the relevant MerchantReturnPolicy.

Do not attach it to Product, Organization, ShippingConditions, MonetaryAmount, or MemberProgram itself. Those entities can connect to the surrounding graph, but they are not listed parents for this eligibility property.

• 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 benefit owner.
2. Use the narrowest supported parent.
3. Reference MemberProgramTier.
4. Validate graph and checkout.

Correct placement prevents one member benefit from unintentionally changing unrelated prices, shipping options, or return terms.

Each MemberProgramTier should have a stable identity that remains consistent across the MemberProgram graph and every validForMemberTier reference.

A tier can specify its program through isTierOf, while MemberProgram can list tiers through hasTiers. Stable @id values prevent Gold on one page from becoming a disconnected text label on another.

Do not join tiers by visible name alone. Multiple programs can have Gold tiers, names can be localized, and programs can rename levels without changing entitlement identity. Use the membership system's canonical identifier.

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.

• Map the member program.
• Assign stable tier IDs.
• Connect each tier to its program.
• Reuse IDs on benefits.
• Audit orphan references.

Tier identity is reliable when every benefit reference resolves to one canonical program tier regardless of page or display name.

Member pricing should place validForMemberTier on the PriceSpecification that contains the member price while retaining an accurate nonmember price for public shoppers.

Gold and Platinum can share one member price specification when both receive the same amount. If tiers receive different prices, use separate specifications. Currency, effective dates, quantity, taxes, and other price conditions still need to match checkout.

Do not attach the tier only to the Offer if just one price is restricted, because that can make the entire Offer appear unavailable to nonmembers. Scope eligibility to the exact price benefit.

• 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. Preserve the public price.
2. Group tiers by identical amount.
3. Create scoped price specifications.
4. Test each account state.

Member pricing is honest when each shopper sees the price tied to their current tier and public shoppers retain a truthful alternative.

A ShippingService can use validForMemberTier to limit a fulfillment option such as free member shipping to the tiers that actually receive it.

The service still needs accurate handlingTime and ShippingConditions for destination, rate, transit, item, weight, and other constraints. Tier eligibility does not erase oversized-product charges, unsupported regions, seller restrictions, or service availability.

Keep a public service available when checkout offers one. A member-only zero-rate service without a public paid alternative can leave signed-out product pages with an incomplete shipping graph.

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 member shipping benefit.
• Attach eligible tiers to the service.
• Preserve public alternatives.
• Preserve all service conditions.
• Test checkout.

Review ShippingService and hasShippingService.

Tier-scoped shipping is correct when membership changes only the intended service benefit and every other condition remains authoritative.

Use validForMemberTier on OfferShippingDetails when a complete Offer-level shipping policy is tier-specific, and on Offer when the entire Offer is available only to certain tiers.

This is broader than restricting one rate or service. If only free shipping differs, ShippingService may be the safer parent. If availability, bundled product access, or all Offer terms are member-only, Offer-level scope may reflect the real contract.

Avoid redundant tier declarations at multiple levels unless they are intentionally consistent. Conflicting tier sets can make an Offer appear valid for Gold while its shipping details apply only to Platinum.

• 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. Determine benefit breadth.
2. Choose the narrowest parent.
3. Detect parent-child conflicts.
4. Test every tier and public state.

See OfferShippingDetails.

Offer-level tier eligibility is well modeled when its scope matches the full set of terms restricted at checkout.

MerchantReturnPolicy can use validForMemberTier when return windows, fees, methods, or other terms genuinely differ by membership tier.

A member benefit might extend a return period or waive a fee, but every condition should match the policy shown after authentication and used by customer support. Public return terms must remain available for nonmembers.

Do not reuse a shipping-tier reference blindly on returns. A tier may include free shipping but no return benefit. Connect each policy only to benefits authorized by the membership program and legal terms.

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.

• Read the return-policy authority.
• Identify the exact member difference.
• Create separate policy when needed.
• Test public and member views.

Member return markup is truthful when tier-specific terms match the operative policy and do not hide the public baseline.

Common mistakes include using text instead of MemberProgramTier, unstable or duplicate tier IDs, wrong parent scope, missing public alternatives, stale benefits, conflicting parent-child tiers, and assuming every named benefit is active at checkout.

Other defects include exposing free shipping to signed-out users, applying a member price to the whole Offer, crossing programs with identical tier names, ignoring expired accounts, and validating syntax without testing authorization states.

Repair the membership, commerce, shipping, and returns sources together. Shared tier references can affect large product cohorts, so stage changes and retain account-state 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 tier reference.
2. Resolve canonical tier identity.
3. Compare benefit scope.
4. Test account states.
5. Repair shared sources.

validForMemberTier defects require identity, scope, entitlement, alternative, and checkout evidence together.