What Is membershipPointsEarned Schema?

membershipPointsEarned states the number of membership points earned by a member.

The property can use Number or QuantitativeValue. When points have a named unit such as stars or miles, QuantitativeValue can use unitText to make that unit explicit.

The number needs an authoritative earning context. A balance, points per purchase, points per dollar, tier multiplier, and transaction award are different facts and should not be collapsed into one unexplained value.

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 what the number represents.
• Choose Number or QuantitativeValue.
• Add unitText when useful.
• Compare the loyalty ledger.

Use the free backlink checker to identify linked loyalty pages before changing shared points markup.

Primary specification: Schema.org definition for membershipPointsEarned.

membershipPointsEarned is accurate when its value, unit, and earning basis match the loyalty system for the referenced context.

membershipPointsEarned can be used on MemberProgramTier, PriceSpecification, and ProgramMembership.

On a tier, it can describe the points associated with that tier's earning model. On a PriceSpecification, it can connect points to a priced transaction context. On ProgramMembership, it can describe points earned for a particular member relationship.

Choose the parent that gives the number its true meaning. Do not attach it directly to Product, Offer, MemberProgram, Organization, or MemberProgramTier benefits without preserving the appropriate entity context.

• 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 points event or rule.
2. Choose the listed parent.
3. Preserve tier and program identity.
4. Validate the full graph.

Review MemberProgramTier schema.

Correct placement makes the points number interpretable as a tier rule, priced earning event, or member outcome.

Use Number for a simple points amount with an already clear unit, and QuantitativeValue when unitText is needed to identify stars, miles, credits, or another program unit.

A bare 500 may be sufficient within a clearly named points program, but 500 Starpoints or 500 miles can be clearer when several loyalty currencies coexist. QuantitativeValue also creates a structured place for the value and unit.

Do not use unitText to describe the earning basis, such as per dollar or per order, unless the target contract genuinely supports that meaning. Keep basis and formula in the loyalty policy.

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.

• List loyalty currencies.
• Decide whether the unit is obvious.
• Choose the smallest complete value type.
• Test parser output.

The value type is correct when it communicates the points unit without inventing an unsupported formula.

The earning basis should be defined in the authoritative loyalty policy so the published number can be interpreted as points per purchase, per currency unit, per item, per price specification, or another verified event.

Taxes, shipping, discounts, coupons, gift cards, tips, excluded categories, marketplace sellers, and regional currencies can change eligible spend. A points number without this context can imply a broader earning benefit than members receive.

Use one calculation source for account messaging, checkout previews, transaction awards, and structured data. Test exact thresholds and rounding at both low and high cart values.

• 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. Name the earning event.
2. Define eligible monetary or item inputs.
3. Define rounding and caps.
4. Compare posted ledger entries.

An earning amount is truthful when every eligible transaction produces the same award under the documented basis.

Tier multipliers should alter the calculated earning outcome only for eligible MemberProgramTier accounts and should not be mistaken for an absolute membershipPointsEarned value.

A Gold member earning two points per dollar and a Silver member earning one point per dollar need distinct tier rules. The final points on a $50 qualifying purchase may be 100 versus 50, but the multiplier and the transaction award are different concepts.

Keep tier identity stable, apply upgrades and downgrades at the correct effective time, and define whether a purchase uses tier status at order, payment, shipment, or settlement.

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.

• Resolve account tier.
• Select the tier formula.
• Apply eligible spend and rounding.
• Post the transaction award.
• Verify ledger.

Tier multipliers are accurate when the correct tier and effective timestamp produce the same transaction award as the ledger.

Refunds, cancellations, chargebacks, and returns should reverse or adjust points according to the loyalty ledger policy rather than leaving the original earning claim permanently unchanged.

Programs differ on pending points, partial refunds, shipping refunds, promotional bonuses, negative balances, and clawback timing. Structured data should not present an award as final when the underlying transaction is pending or reversed.

Test full and partial refunds, canceled orders, returns after redemption, chargebacks, split shipments, and marketplace settlements. Preserve event history rather than rewriting prior ledger records without traceability.

• 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 award state.
2. Apply refund policy.
3. Post reversal event.
4. Update member-facing balance.
5. Recheck structured outcome.

Points remain trustworthy when every reversal and adjustment matches the loyalty ledger's event history.

Promotional bonus points should be modeled as time-bound earning behavior and kept separate from a tier's permanent baseline unless the bonus genuinely becomes an ongoing tier benefit.

A weekend 3x campaign, category bonus, signup award, referral award, and birthday bonus have different eligibility and effective periods. Copying a temporary rate into MemberProgramTier can leave stale promises after the campaign expires.

Define stacking order between tier multipliers, coupons, category bonuses, and caps. Test campaign start, exact end, time zone, eligible products, account cohorts, and rollback to baseline.

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 baseline earning.
• Identify promotional delta.
• Define stacking and caps.
• Apply effective period.
• Test rollback.

Promotional points are accurate when their cohort, period, stacking, and rollback match the campaign engine.

Common mistakes include publishing a number without basis, confusing a balance with an earning rate, using the wrong parent, omitting unitText for multiple currencies, treating multipliers as absolute points, and ignoring refunds or pending states.

Other defects include stale promotions, tier-ID drift, rounding mismatch, currency conversion errors, points awarded on excluded spend, duplicate ledger events, and valid markup that disagrees with account history.

Repair the loyalty policy, transaction calculator, ledger, and structured-data generator together. Points are financial-like customer value, so use traceable events and regression transactions.

• 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 points value.
2. Resolve parent and meaning.
3. Compare formulas and ledger events.
4. Test adjustments and promotions.
5. Repair shared sources.

membershipPointsEarned defects require semantic context, unit, formula, tier, transaction, and ledger evidence together.