What Is hasTierRequirement Schema?

hasTierRequirement describes what a user must satisfy to join a MemberProgramTier.

The property can use CreditCard, MonetaryAmount, Text, or UnitPriceSpecification. These value types cover card-linked eligibility, minimum spend, custom requirements, and recurring or one-time fees.

A free-to-join tier does not need the property. Requirements should come from the operative membership contract and enrollment system, not from marketing shorthand or inferred benefits.

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 actual enrollment rule.
• Choose the closest supported type.
• Preserve money and billing context.
• Test eligibility.

Use the free backlink checker to identify linked membership pages before changing tier-entry requirements.

Primary specification: Schema.org definition for hasTierRequirement.

hasTierRequirement is accurate when the same condition controls real enrollment, renewal, upgrade, and account entitlement.

hasTierRequirement is used on MemberProgramTier and should contain one of its four supported value types.

Do not attach it directly to MemberProgram, Offer, PriceSpecification, ShippingService, Organization, or ProgramMembership. Those entities can define the program, benefit, host, or member state, but the join requirement belongs to the tier.

Connect the tier to its parent program and preserve stable identity. A requirement attached to an unresolvable or duplicate tier cannot reliably scope enrollment behavior.

• 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 requirement there.
3. Keep program identity intact.
4. Validate the rendered graph.

Review MemberProgramTier schema.

Correct placement keeps enrollment criteria tied to the tier that actually grants access.

Use CreditCard when joining the tier requires signup for or possession of a specific credit-card product.

The card entity should identify the real product or eligibility condition without exposing private account data. A co-branded card tier and a general paid membership are different requirements and should not share the same value type merely because both involve payment.

Test new applications, existing cardholders, declined or closed accounts, replacement cards, authorized users, and program termination. Enrollment authority must decide eligibility.

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 required card product.
• Publish only public product identity.
• Connect it to the tier.
• Test card-account states.

A CreditCard requirement is truthful when card-program status, not merely a past payment, controls tier access.

Use MonetaryAmount when a user must reach a minimum monetary amount, such as qualifying spend, to join the tier.

Include value and currency and define the measurement period in the authoritative membership source. Lifetime spend, calendar-year spend, rolling twelve-month spend, and one transaction are materially different criteria even when the threshold number matches.

Clarify whether taxes, shipping, discounts, gift cards, refunds, returns, cancellations, and excluded products count. Structured data should reflect the enrollment calculation rather than inventing a subtotal formula.

• 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 threshold and currency.
2. Document measurement period.
3. Define eligible transactions.
4. Compare membership ledger.

A monetary requirement is accurate when the same spend calculation and currency determine live tier qualification.

Use UnitPriceSpecification when joining or retaining the tier requires a fee with pricing context such as amount, currency, and billing period.

An annual $39.99 membership and a monthly $4.99 membership are not equivalent. Reference quantity and unit codes can preserve the billing cadence, while effective dates and renewal behavior remain in the commercial source.

Test trial conversion, renewal, cancellation, failed payment, grace period, tax, refund, price change, and regional currency. Do not publish an old fee after the billing system has migrated members.

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.

• Capture amount and currency.
• Capture billing cadence.
• Capture effective policy.
• Test billing and entitlement states.

A paid-tier requirement is truthful when the published fee and cadence match enrollment and renewal checkout.

Use Text for a tier requirement that cannot be accurately represented by CreditCard, MonetaryAmount, or UnitPriceSpecification.

Examples might include verified professional status, invitation, employer affiliation, or another program-specific condition. The text should be concise, public, and operationally enforced rather than vague marketing language.

Prefer structured types when they fit. Do not use Text to hide missing currency, billing cadence, or spend threshold details, and never include sensitive verification data.

• 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. Confirm no structured type fits.
2. Write a concise public requirement.
3. Exclude private evidence.
4. Test enrollment enforcement.

A text requirement is appropriate only when it expresses a real public eligibility rule that richer supported types cannot represent.

Free-to-join tiers can omit hasTierRequirement, while tiers with multiple independent or combined requirements need a graph that matches the real enrollment logic.

Do not add zero MonetaryAmount merely to signal free access when the property can be omitted. If a tier requires both a fee and verified status, record the supported requirements only when the target consumer can interpret their relationship and the enrollment source enforces both.

Distinguish AND from OR logic. A user who qualifies through spend or a card should not be modeled as if both are mandatory. When representation is ambiguous, prefer a narrower truthful description over invented logic.

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 whether access is free.
• List every real requirement.
• Document AND or OR logic.
• Validate consumer representation.
• Test enrollment cohorts.

Free and multi-requirement tiers are accurate when omission and requirement logic mirror the enrollment decision exactly.

Common mistakes include adding requirements to free tiers, using the wrong value type, omitting currency or billing period, publishing vague Text, confusing benefits with entry criteria, exposing sensitive data, and attaching the property to the program instead of the tier.

Other defects include stale fees, wrong spend periods, refunded purchases still counted, card account states ignored, ambiguous AND-or-OR logic, duplicate tier identities, and valid markup that disagrees with enrollment.

Repair the membership, billing, card, and loyalty-ledger sources together. Entry rules affect every dependent benefit, so stage changes and retain enrollment regression 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. Crawl every requirement.
2. Validate parent and type.
3. Compare money and period details.
4. Run eligibility scenarios.
5. Repair shared sources.

Requirement lifecycle deserves its own regression matrix. Test fee increases, grandfathered prices, trial conversion, renewal dates, failed-payment grace periods, card replacement, spend-window resets, returns that reduce qualifying spend, tier downgrades, and requalification. Preserve the distinction between the rule for new applicants and the rule for existing members: a legacy member may retain access under old terms while a new applicant must satisfy the current requirement. Publish only the requirement that applies to the referenced tier cohort and effective period.

hasTierRequirement defects require semantic type, money, logic, privacy, identity, and live enrollment evidence together.