Member Labels

A label is a tag — NEWSLETTER, TRADE-IN-DONE, GSO-LAUNCH — and a member can carry any number of them, where a class is one tier per member. Labels sit inside label lists, which group them (a list CAMPAIGN holding GSO-LAUNCH and BLACK-FRIDAY). Tagging a member writes one link row and nothing else: no points, no journal, no price change at the till, no message to the member. Everything a label does, it does because some other rule reads that row later — and the rules differ far more than their names suggest. This page is for whoever plans campaigns or segments on labels, and names each reader and what it does with a label.

Who reads a label, and which of them read it properly

Where you pick a label	What actually happens
Web store (CP Commerce): a voucher’s rules, a coupon at checkout, a Shipping Pricebook rule	Honoured, label by label. The store reads the labels of the membership tied to the signed-in account, and the website’s voucher list is filtered by them on the server before the shopper sees it.
Pricebook Member Label header rule	Ignored at the counter and on sales documents — the till and the sales-document calculators treat the rule as satisfied, so it widens the price set instead of narrowing it. The web store and the OCR receipt processor do compare the labels.
Commission Scheme Member Label rule	Passes for any member who holds any label at all; the labels you picked are not compared. Until that rule is corrected, a labelled segment for commission is a class.
CP Commerce Admin → Topics → Member Label Link	A separate run subscribes the labelled members’ registered app devices to the topic, in one direction only; removing the label removes nobody. The run is a clock created from that screen — check it exists before you promise anyone a push.

So the honest one-line rule: a label is an online and marketing segment; a class is a counter segment. If the behaviour you want is a price or a commission at the till, use a class instead of a label. If it is a voucher, a shipping rate or a push notification for a group of members, a label is the right tool and the only one that holds several per member.

Why bother, when the till ignores them

GadgetSphere Online (GSO) launches its web store. Marketing tags the 1,200 members who pre-registered with GSO-LAUNCH (list CAMPAIGN), once, by CSV. From that one tag: a launch voucher whose Doc Hdr rule is Member Label = GSO-LAUNCH appears in those members’ accounts and in nobody else’s; a shipping price set with the same rule gives them free delivery for the month; the label linked to a Launch week topic puts the announcement on every registered phone. Three systems, one segment, maintained in one place — and the counter staff never see any of it, which is the point: the launch is online-only.

Two quieter uses. The Security and Compliance page asks you to make staff cards identifiable before you issue the first one; a label used for nothing else does that without touching the tier. And the label’s own Members tab lists every member carrying it, read from the link rows at the time of opening — so a label is also the cheapest way to keep a named list you can scroll and act on (trade-in done, warranty registered, attended the event), which matters because the Membership Report carries no label column.

Labels are rare in practice, and close to half of the labels that get created are attached to no member at all: created, never used. A label with no member and no rule reading it is a word in a list.

Before you create one

The order is list, label, member. A label requires a label list — the create screen refuses without one — and a member can only be tagged with a label that already exists, whether on the Labels tab of Membership Edit or through LABEL 1…3 of the Upload Membership CSV.
The code is forced to upper case as you type it, and is read-only once saved. You can rename a label or move it to another list later; its code you cannot touch.
Choose codes with the CSV in mind. The upload resolves each LABEL column by code alone, across every list, and nothing stops two labels sharing a code — the upload then takes whichever row it finds first — and a deleted label keeps its code, so the upload can land on the dead one. Keep codes unique across all lists and never reuse a deleted one; retire a label by unlinking its members, not by re-creating it.
ENABLE_WEBSITE_SELECTION_ON_MEM_LABEL_LINK (Membership Admin → Field Settings) adds a website picker to the label’s Members tab when you add members there. The website is the push-notification context for the topic run above; it changes nothing about the link itself.
Tagging leaves no Audit Trail row. Creating, renaming or deleting a label does; linking a member to one does not, from either side. If who-tagged-whom matters, the label’s Members tab shows only the modified date.

When it goes wrong

Symptom	Cause	Fix
Upload Membership rejects a row with The label code: vip provided is invalid	The code is matched exactly, and the screen stored it as `VIP`; or the label does not exist yet; or you typed the list code	Create the label first, then type its code as the Member Label listing shows it
A Member Label price rule changes nothing at POS or on a sales invoice	The till and sales-document calculators ignore that rule type	Use a Member Class rule; keep label rules for the web store
A commission rule meant for one label pays every member	The rule only checks that the member holds some label	Qualify by Member Class until the rule is corrected
You deleted a label and the commission rule still pays its members	Deleting a label leaves its member links in place, and that rule reads the links	Unlink the members on the label’s Members tab (select, Delete) before you delete the label
Labelled members get no push notification	The member has no registered app device, or no topic run has been set up for the label	CP Commerce Admin → Topics: link the label and create the run; a member without the app is never reached
A labelled member does not see the voucher online	The store reads the labels of the membership tied to the signed-in account; a member record with no login, or a second record for the same person, carries none	Check which member record the account is linked to, and tag that one
The search box on the member’s Labels tab finds nothing, or everything	That search only reloads the list; it does not filter	Scan the list — it is short by design

What labels do not do

Nothing attaches or removes a label by itself. There is no spend, visit, birthday or recency trigger: a person, the CSV upload or an integration through the API does it. If “spent RM 5,000 in twelve months” should earn a tag, that is a report somebody runs each month and a CSV they upload — decide who, and on what day.
The till does not read them. Counter pricing and commission are class territory (see the table above).
The Membership Report does not carry them. The segment list is the label’s Members tab.
A label’s status is not what the rules read. The web store drops a deleted label; the commission and OCR rules read the member’s link rows, so a label you want out of play needs its members unlinked.
Labels do not expire. A campaign tag stays until somebody removes it, which is why a dated code (GSO-LAUNCH-2026) ages better than LAUNCH.

How you know it worked

Thirty seconds, two screens. Open Membership Admin → Member Label, pick the label, Members tab: the member you tagged is in the list (it is read fresh from the links each time you open it). Open the member, Labels tab: the list and the label are there. If the point was the web store, sign in as that member on the site and open the vouchers page — the labelled voucher is listed and the others are not. If the point was a push, the test is a registered phone receiving one, not a row on a screen.