What Is membershipNumber Schema?

membershipNumber is the Schema.org property for a unique Text identifier assigned to a ProgramMembership.

It can represent a loyalty account number, club member code, frequent-traveler identifier, or another membership-specific key. Its simple definition hides an important implementation issue: identifiers often belong to a person and can be sensitive even when they are not passwords. The subject must be ProgramMembership and the value is Text. A valid property is not automatically appropriate for public markup; the page context, authorization, exposure path, and business need must all justify including it.

• Use membershipNumber only on ProgramMembership.
• Provide a Text value when inclusion is justified.
• Treat the identifier as customer data, not SEO copy.

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.

Primary specification: Schema.org definition for membershipNumber.

membershipNumber models an identifier, but safe use depends on privacy and page context as much as syntax.

membershipNumber is used on ProgramMembership and should not be attached directly to Person, Organization, MemberProgram, Offer, or Reservation.

A Person can be connected to a ProgramMembership through memberOf, and a ProgramMembership can connect to its MemberProgram through program. A Reservation can reference a membership being applied through programMembershipUsed. The number stays on the membership entity because it identifies the relationship, not the person or program independently. Keeping that boundary matters when one customer has several memberships or when the same program serves many customers.

1. Declare or reference the ProgramMembership.
2. Connect the membership to its program separately.
3. Attach the identifier only to the membership node.
4. Avoid copying the number onto related entities.

• 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

Keep the number on its membership record and use relationship properties to connect the rest of the graph.

A real customer membership number should generally not appear in public JSON-LD because machine-readable HTML can be copied, indexed, logged, or collected by third parties.

Public loyalty pages rarely need an individual account identifier to explain the program. They should model MemberProgram, MemberProgramTier, benefits, requirements, and eligible offers instead. Even an authenticated page deserves caution: structured data adds another copy of the value to the document and may expose it to browser extensions, analytics collectors, tag managers, error tools, screenshots, or cached responses. Omission is often the strongest implementation.

• Omit real membership numbers from public marketing pages.
• Prefer program and tier entities for public SEO content.
• Minimize identifiers even behind authentication.
• Use synthetic values only in controlled documentation examples.

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.

If a page can work without the number, omission reduces risk without weakening the program entity graph.

Masking reduces visual exposure but does not make a membership identifier safe if the full value remains elsewhere in HTML, JSON-LD, attributes, scripts, or network responses.

A page can display •••• 4821 while silently embedding the complete number in a script object, analytics event, data attribute, or hydration payload. Inspecting only the visible screen misses those copies. A safe implementation traces the value from database query through server rendering, client state, telemetry, and response caching. Partial values may still identify someone when combined with name, email, program, location, or reservation data.

1. Inspect the raw HTML response.
2. Search JSON-LD and script state objects.
3. Review data attributes and hidden inputs.
4. Inspect network requests and telemetry payloads.
5. Confirm caches vary by authorization and account.

• 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

Masking is useful presentation, but real protection requires removing the full identifier from every unnecessary data path.

Documentation examples should use obviously synthetic membership numbers and state that production identifiers should be omitted unless a justified private context requires them.

Avoid examples that resemble real customer formats closely enough to be mistaken for live data. Do not paste screenshots, support tickets, exported account rows, or production JSON into an article. When demonstrating ProgramMembership, the program relationship, tier, and points concepts can usually teach the model without any number at all. If the property is the subject of the example, use a placeholder such as DEMO-MEMBER-0001 and keep it out of production templates.

1. Create an unmistakably synthetic value.
2. Label the example as non-production data.
3. Avoid matching a real account format when possible.
4. Keep fixtures isolated from live rendering paths.
5. Scan examples before publication.

• 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

Examples should teach the property without normalizing the publication of live customer identifiers.

Templates can leak membership numbers through structured data blocks, HTML attributes, client hydration, debugging output, and shared caching even when the visible page is masked.

A backend serializer may include every account field by default, and a frontend may hide the value only after download. Server-side rendered JSON can be captured by view-source or monitoring tools. A shared cache key can accidentally serve one customer’s membership data to another. Schema generation should use a deliberate allowlist rather than serializing an entire membership model. Every output path needs authorization checks before rendering, not only CSS concealment afterward.

• Use field allowlists for structured output.
• Exclude account identifiers from generic serializers.
• Authorize before server rendering.
• Keep customer-specific responses out of shared caches.
• Remove debug dumps from production templates.

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.

Preventing leakage starts before rendering: only necessary, authorized fields should enter the response at all.

Analytics and logs can turn a limited membershipNumber exposure into persistent copies across systems with broader access and longer retention.

Auto-capture tools may record text, attributes, form values, or DOM mutations. Error trackers can attach request bodies and page state. Access logs may store membership numbers when they appear in URLs or query parameters. Session replay can preserve masked-looking interactions if masking rules are misconfigured. Treat every third-party collection path as a separate data destination and verify behavior with controlled synthetic accounts rather than assuming vendor defaults.

1. Inventory analytics, replay, error, and log systems.
2. Search payloads for synthetic membership identifiers.
3. Disable capture at the source where possible.
4. Apply redaction before transmission and storage.
5. Set appropriate access and retention controls.

• 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

A number removed from the page can still persist elsewhere, so telemetry and logging need direct verification.

Common mistakes include publishing real identifiers, attaching the property to the wrong type, confusing it with points or program identity, and relying on visual masking.

Teams may also use a Number value and lose leading zeros, expose the number in a canonical URL, or duplicate it into analytics events. Because the expected type is Text, identifiers like 001284 should remain text when they are legitimately processed. MembershipPointsEarned is for balances, while program is for the associated MemberProgram. Neither should be overloaded with an account identifier.

• Real number embedded on a public page.
• Number type used for an identifier with leading zeros.
• membershipNumber placed on Person or MemberProgram.
• Full value hidden only with CSS.
• Identifier sent in URLs, logs, or analytics.

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.

Correct typing matters, but preventing unnecessary disclosure is the higher-priority quality bar.