Tagging and segmenting customers automatically
Every conversation tells you something. Three blocks decide whether you still know it next month.
A tag is a label on a customer; a contact field is a value stored against them; flow memory is a note that only matters for the conversation happening now. Choosing between the three is the whole of getting this right, and most confusion comes from using one where another belongs.
The payoff is not tidiness. It is that six weeks later you can send a message to exactly the people it applies to, instead of everybody.
The three places a flow can record something
| Block | Stores | Good for |
|---|---|---|
| Update Customer Tags | A label from a list you defined | Groups you will message later: VIP, wholesale, opted out |
| Update Customer Attribute | A value in a named field | Facts about the person: city, size, birthday, order number |
| Remember Info | A key and value for the flow | Working state inside a conversation |
The rough test: if you would ever want a list of everyone like this, it is a tag. If it is a fact with a value, it is a field. If it stops mattering when the conversation ends, it is memory.
Tags, and the one thing that catches people out
Tags are chosen from a list your organisation defines, and the block references them by their id rather than by typing a name. That is deliberate — it means a tag cannot be created by accident with a typo, and a flow cannot quietly start writing "VIp" alongside "VIP".
The practical consequence is that you create the tag first, in your tag settings, and then point the flow at it. A flow referencing a tag that does not belong to your organisation does nothing at all, silently, which is exactly the sort of failure worth knowing about in advance.
Tags support three actions. Add is the common one. Remove is how you undo a state — a customer who was "awaiting payment" and has now paid. Replace swaps the whole set, which is occasionally what you want for a status-style tag and almost never what you want otherwise.
Shopify order tags are a different thing
Worth flagging because the names collide. There is also an Update Shopify Order Tags block, and it writes free-text tags onto the order in Shopify, not onto the customer here.
Both are useful and they serve different audiences. Customer tags are for deciding who to message; Shopify order tags are for your packing team, who filter the orders list by them. A confirmed cash-on-delivery order usually wants both.
Contact fields, and defining them first
A contact field has to exist before a flow can write to it. Define it in your contact settings, then reference its key in the flow.
Skip that and the value goes somewhere you cannot see — no error, no warning, just a field that stays empty when you go looking for it. It is the single most common reason someone reports that saving answers "does not work".
Two ways to fill a field:
- Straight from a question. The Ask Customer a Question block can save the answer directly, which is the cleanest route for anything the customer tells you.
- With Update Customer Attribute. For anything the flow worked out rather than asked — a calculated total, a value looked up in a sheet, a field returned by your own system.
Once a field is populated you can use it in message text, branch on it, and filter on it when building an audience.
A flow that sorts as it talks
Qualify and label in one pass
Two branches, one tag each, and from then on your wholesale enquiries are a group you can address rather than something you remember about individual chats.
Branching on what you already know
Recording is only half of it. Three blocks read the record back:
- A tag guard stops a flow for anyone without the right tag — the natural way to make a message wholesale-only.
- If Customer Info (Yes/No) branches on whether a piece of remembered information exists.
- If Customer Info (stops if missing) ends the run when it is not there, which is the safe default before a message that would read oddly with a blank in it.
That last one deserves a habit: any message containing a variable should be preceded by something that checks the variable is filled. A message that says "your order is on its way" reads fine; the same message with an empty tracking number does not.
What to tag, and what not to
The failure mode is forty tags nobody can remember the meaning of. A short list that gets used beats a comprehensive one that does not.
| Worth a tag | Better as a field |
|---|---|
| Wholesale customer | Company name |
| Opted out of marketing | Date of last order |
| Bought in the last 90 days | Order number |
| Asked about a specific range | Preferred size |
| Came from an ad | City |
Note the pattern: tags answer "which group", fields answer "what value". A tag per city is a list you will regret; a city field is a filter that keeps working as you add cities.
Turning tags into an audience
The reason to do any of this is the message you send later. Tags and fields are what audience filters read, so a flow that tags properly today is a broadcast you can target precisely next month — the mechanics are in building audiences with segments.
Which is also the discipline: before adding a tag, name the message you would send to the people who have it. If you cannot, the tag is not earning its place.
Tags and the rules
Two things a tag does not do. It does not create permission — a marketing template still requires opt-in, whatever the customer is labelled as. And it does not change reach: your messaging tier caps unique recipients per rolling 24 hours regardless of how the audience was built, and marketing templates carry a per-user limit Meta deliberately does not publish a number for.
What a good tag does is make the message relevant, which is the thing that keeps your quality rating healthy — and free-form replies inside the 24-hour window remain free under Meta's pricing documentation, so precision costs you nothing on the service side.
Frequently asked
Can a customer have several tags?
Yes, and most useful setups rely on it — wholesale and opted-in and bought-this-quarter is three tags describing one person.
Do tags leak between organisations?
No. Tags belong to your organisation. That is also why copying a rule between organisations needs its tag references re-pointed.
What if I need a tag that does not exist yet?
Create it in your tag settings first, then select it in the block. A flow cannot invent one.
Should the customer know they have been tagged?
They never see it. Tags and fields are internal, which is also a reason to keep the wording of them businesslike — someone else will read them.
Flow memory, and why it is separate
The third block, Remember Info, stores a key and a value that the flow can read back later. It is deliberately lighter than a contact field: nothing to define in advance, and nothing that clutters the customer record.
Use it for working state — which branch the customer took, whether they have already been shown the size guide, what they picked before you asked the follow-up question. Two blocks read it back, one that branches yes or no on whether the value exists and one that stops the run when it is missing.
The line is worth holding. If your team would ever want to see it on the contact, it belongs in a field. If it exists to keep the flow honest for the next three steps, memory is the right home for it, and the customer record stays readable.
A tagging plan a small store can maintain
- Start with five tags, and write the message you would send to each group next to it.
- Add tags from flows, not by hand. Anything that depends on somebody remembering will be applied inconsistently within a month.
- Remove tags as deliberately as you add them. A status tag that is never removed becomes a permanent label that means nothing.
- Review them quarterly alongside your templates, and delete anything you have never used to target a message.
- Keep opt-out separate and absolute — it is the one label that must be checked before any marketing send.
Five tags applied consistently by a flow will outperform forty applied by hand, because the audience you build from them is actually accurate.
What this buys you six weeks later
Everything above is invisible on the day you build it. The return arrives when you want to send a message to 200 wholesale customers rather than to your whole list — a distinction that matters both for relevance and for reach, since your messaging tier caps unique recipients per rolling 24 hours on the ladder 250 → 2,000 → 10,000 → 100,000 → unlimited in Meta's messaging limits documentation.
Sending to the right 200 instead of the wrong 2,000 is cheaper, safer for your quality rating, and more likely to sell something. Tags are how a flow makes that possible without anybody keeping a spreadsheet. The flows that collect the answers in the first place are in saving customer answers to contact fields, and the alerting side in internal notes and team alerts.