Good targeting starts with a good list, and the raw material is your order history: who bought twice, who spent over a threshold, who only ever bought the one product and might come back for the rest. Pulling that by hand across orders and customers is the tedious part. This does the cross-referencing and hands you a clean segment. It is honest about where it stops: it builds the list, it does not send anything.
Build me a customer segment. Read only, change nothing. I want [customers whoplaced 2 or more orders in the last 6 months and spent over 200 total].
Work from the orders in that window, match them back to the customers behindthem, and pull each qualifying customer's name and email. Then give me thefinished segment as a plain-text table: name, email, order count, total spent,and a one-line note on why each one qualified, so I can drop it straight intomy email tool. Do not contact anyone; just hand me the list.Why this is safe to run
This is a partial recipe by design, and the honest boundary is worth stating plainly: it reads. It can list orders, list customers, and read a customer’s details to build the segment, and that is the end of what it does. There is no ability here to send an email, tag a customer, or push the list into another system, so the agent hands you the segment and the acting stays with you.
Because it is all reads, nothing on the store changes: no order, no customer, no record is touched. The one thing to keep in mind is that the list includes real customer emails, so treat the output the way you would any export of personal data. Every read runs against the capability of the user you bound the agent to and lands in the Activity Log.
Already connected? Skip the paste. Ask your agent for the “build a customer segment from order history” recipe, or just describe the segment you want, and it runs the same reads on your own store and hands you the list.