What Is MemberProgramTier Schema?

MemberProgramTier is a Schema.org type representing a specific tier within a loyalty or membership program, such as Silver, Gold, or Platinum.

A tier can identify its benefits, entry requirements, parent MemberProgram, and membership points earned. Other entities can reference it through validForMemberTier to scope prices, Offers, shipping services, shipping details, or return policies.

The type is in Schema.org's new area. Validate the tier graph, target-consumer support, and live membership behavior separately. A named tier is accurate only when its requirements and benefits match the membership system.

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 each real program tier.
• Assign stable entity IDs.
• Add verified requirements and benefits.
• Connect the parent program.

Use the free backlink checker to find linked program pages before changing shared tier entities.

Primary specification: Schema.org definition for MemberProgramTier.

MemberProgramTier is correct when one stable entity represents one real tier with the same entry rules and benefits members receive.

Each MemberProgramTier should have a stable @id that distinguishes it from similarly named tiers and survives display-name changes.

Gold is not a globally unique identity. Multiple programs, brands, countries, or legacy versions can use the same visible name. Build the identifier within the authoritative MemberProgram namespace and reuse it across every benefit reference.

Do not create a fresh blank node on every product page if the tier is the same entity. Duplicate tier nodes can drift in benefits or requirements and break large-scale audits.

• 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. Map programs and markets.
2. Assign canonical tier IDs.
3. Reuse IDs on every page.
4. Detect duplicate and stale entities.

Tier identity is trustworthy when every reference resolves to one canonical tier inside one canonical program.

isTierOf connects MemberProgramTier to its MemberProgram, while hasTiers provides the inverse program-to-tier relationship.

A program may contain several tiers with different requirements and benefits. Stable bidirectional identity helps crawlers and internal systems distinguish a tier from another similarly named tier outside the program.

Do not connect one tier to multiple unrelated programs unless the membership authority genuinely defines that shared entity. Regional or branded variations normally need explicit program boundaries.

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 MemberProgram entity.
• List canonical tiers.
• Connect each tier back to the program.
• Validate IDs in both directions.

Program relationships are coherent when every tier belongs to the same program that publishes and enforces its membership rules.

hasTierBenefit can identify loyalty points, loyalty pricing, loyalty returns, and loyalty shipping through TierBenefitEnumeration members.

The enumeration declares the benefit category, not every operational detail. TierBenefitLoyaltyShipping does not prove free worldwide express shipping; the actual ShippingService and its conditions must define price, destination, timing, and exceptions.

Add only benefits the tier currently provides. If a tier includes points and shipping but not special returns, publish those two categories and leave returns out.

• 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. Read the membership contract.
2. Choose supported benefit members.
3. Connect detailed benefit entities.
4. Test member outcomes.

Tier benefits are accurate when each enumeration member is backed by a working price, points, shipping, or return policy.

hasTierRequirement can use CreditCard, MonetaryAmount, Text, or UnitPriceSpecification to describe what a user must satisfy to join the tier.

CreditCard fits a card-linked tier, MonetaryAmount can express minimum spend, UnitPriceSpecification can express a periodic fee, and Text can cover a requirement not represented by the richer types. A free tier does not need this property.

Use the most structured value supported by the membership source. Include currency, billing period, and amount where relevant, and never turn an aspirational upgrade message into an eligibility requirement.

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 legal join requirement.
• Choose the closest supported type.
• Preserve money and period details.
• Test enrollment eligibility.

A tier requirement is truthful when the same condition controls real enrollment and account upgrades.

membershipPointsEarned can use Number or QuantitativeValue to state the points a member earns, with unitText available when the program uses stars, miles, or another named unit.

The numeric value needs a clear earning basis in the source policy. Ten points per purchase, ten points per dollar, and a balance of ten points are different facts; the tier property should not blur them.

Use QuantitativeValue when the unit name materially clarifies the program. Audit multipliers, currencies, eligible products, refunds, promotions, expiration, and rounding in the loyalty engine before publishing a value.

• 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. Define the earning basis.
2. Choose Number or QuantitativeValue.
3. Add unitText when useful.
4. Compare loyalty ledger outcomes.

membershipPointsEarned is useful only when its number and unit describe the same earning rule the loyalty ledger applies.

Other entities use validForMemberTier to connect specific member prices, shipping benefits, Offers, shipping details, or return terms back to a MemberProgramTier.

Keep the tier entity focused on identity, requirements, benefits, program, and points. Put price amounts on PriceSpecification, shipping conditions on ShippingService or OfferShippingDetails, and return details on MerchantReturnPolicy.

This separation lets one tier reference several benefits without duplicating the tier definition. It also preserves public alternatives for nonmembers and narrower conditions for destinations or products.

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.

• Build the canonical tier.
• Build each detailed benefit policy.
• Reference eligible tiers.
• Retain public alternatives.
• Test account states.

Use validForMemberTier and ShippingService for detailed eligibility and shipping relationships.

Tier relationships are well modeled when eligibility stays centralized while each benefit retains its own operational facts.

Common mistakes include text-only tier names, duplicate or unstable IDs, orphan tiers, wrong parent programs, unsupported benefit values, vague requirements, missing currency or billing period, and points without a clear earning basis.

Other defects include benefits that do not exist at checkout, stale retired tiers, crossing programs with the same name, missing public alternatives, and valid syntax that disagrees with enrollment or loyalty ledgers.

Repair the membership authority and structured-data generator together. Tier entities are shared across many Offers, so stage changes and retain account-state, enrollment, points, price, shipping, and return regression tests.

• 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 entity.
2. Resolve canonical program identity.
3. Validate benefits and requirements.
4. Compare account and checkout behavior.
5. Repair shared sources.

Tier lifecycle rules also need explicit ownership. Test upgrades, downgrades, grace periods, renewals, cancellations, merged tiers, and program sunsets because a stable identifier can remain in old pages after entitlement has changed. Preserve effective dates and a migration map from old tier IDs to current policies, but never redirect two historically different benefit sets into one tier until membership and checkout behavior prove they are equivalent.

MemberProgramTier defects require identity, program, benefit, requirement, points, and live entitlement evidence together.