Every course seller ends up with a spreadsheet. It holds the things Shopify has nowhere to put: which cohort a student is in, who is paying for their seat, the licence number that has to appear on their certificate, where the referral came from. It is accurate on the day it is made and wrong within a month.
Alva Courses is a Shopify app for building and selling online courses, and contact properties are where that spreadsheet is supposed to live instead. This article covers what belongs in one, how to fill them in at scale from a CSV import, and how they come back out in the member export.
Why the spreadsheet goes stale
A side spreadsheet has no connection to the thing it describes. Students enrol, change email address, get refunded, join a second cohort — and none of that reaches the file. Worse, the person who maintains it is usually the person who is busiest, so it decays fastest exactly when the programme is growing.
The Shopify customer record does not solve it either. It is built around buying: name, addresses, orders, tags, marketing state. A course seller needs facts about the student as a learner, and the customer record has no field shaped like that.
Tags are the usual workaround and they are the wrong tool for most of this. A tag is a flag, not a value. It can say a student is in the spring cohort; it cannot hold a licence number, an employer name or a date, and a store that tries ends up with hundreds of single-use tags nobody can search.
What belongs in a contact property
A contact property is a named value stored against one member for your store. It is for a fact about that person that you know and Shopify does not, and that you will later want to read on their member page or pull into an export. It is free text, so it holds whatever your programme actually needs.
- Cohort or intake — spring_2026, march_group, the thing you sort students by when you run a live session.
- Employer or sponsor — who bought the seat, when the student is not the buyer.
- Licence or registration number — the identifier a professional body wants on a continuing-education record.
- Referral source — the partner, affiliate or event that sent them, kept per student rather than guessed from an order.
- Programme detail — a mentor's name, a seat number, a renewal date, a purchase-order reference for an invoiced student.
Two things to keep out. Do not duplicate what Shopify already holds well — name, email, order history — because the copy will drift from the original. And be careful with sensitive detail: a contact property is personal data you authored about someone else, and it is subject to the same requests as everything else you hold. Student data and GDPR for course sellers covers that side.
How contact properties work in Alva Courses
Contact properties sit on the member's own page in the admin, described there as custom properties you attach to this contact. You add a property, give it a name and a value, and save. Editing and deleting are on the same card. There is no schema to define first, so a new property can be invented the moment you need it.
The naming rules, and why they exist
A property name uses lowercase letters, numbers and underscores, between 3 and 64 characters — licence_number, cohort, employer. The constraint is not decoration. A stable machine-readable name is what lets the same property become a column heading in an export and a suggestion the next time you add one, instead of five near-identical spellings of the same idea.
A store can have up to 100 distinct property names. That cap is generous for a real programme and deliberately not unlimited, because every name is a potential column in your member CSV and an export a thousand columns wide helps nobody. Existing properties stay editable at the cap; you just cannot invent a new name until you retire one.
A few names are reserved because the CSV importer already owns them — email, first_name, last_name and the course columns. Trying to use one is refused with an explanation rather than silently accepted and then ignored at import time.
They are yours alone
One person can be a customer of many stores running the same app. Contact properties are stored per store, so what you record about a student is visible only to you — never to another merchant who happens to have the same customer, and never on their member page.
Filling them in at scale from a CSV import
Typing properties one member at a time is fine for a handful and hopeless for a cohort. The member importer handles the bulk case: any column in your CSV that is not part of the standard member import is offered as a contact property, and you decide column by column which ones to keep.
Extra columns are unticked by default, so nothing is created behind your back. Tick a column and it is imported as a property; leave it and it is ignored. This is where the spreadsheet finally becomes real data instead of a parallel universe.
Because spreadsheet headings are prose, the importer shows you the property name it proposes for each column before anything is saved. A column called Licence Number becomes licence_number, and you see that rewrite rather than discovering it afterwards. Columns that cannot be turned into a valid name, or that collide with a reserved one, are explained rather than dropped in silence.
Getting them back out: exports
A property nobody can extract is just a note. Every contact property your store uses is available as its own column in the member CSV export, alongside the standard member columns, so the export can answer the question the spreadsheet used to answer — and this time it is generated from live data.
The export column picker separates member columns from contact properties, so you can build a file that is exactly the cohort report you need rather than everything the app knows. If you run the same report every month, save the selection as a column set and reuse it, with one set as your default.
From there the file goes wherever your work happens: an invoice run for a corporate sponsor, a cohort list for a live session, a continuing-education submission that needs licence numbers beside completion dates. See export members to CSV for the export itself and contact properties for the field-by-field detail.
Putting a property into the email itself
An export tells you something about a cohort. A merge variable tells the student something about themselves, which is the point at which a stored property stops being admin and starts being teaching. Every property your store uses becomes a placeholder in the course email templates, written as {contact.your_key} and offered by the editor's Insert Variable panel beside the standard course and customer placeholders.
That turns one enrolment email into the right enrolment email for every intake: name the cohort the student has actually joined, the sponsor who bought their seat, or the mentor they have been assigned, without maintaining a separate template per group. Keep one rule in mind — a student with no value saved for that property gets an empty space, not the placeholder text — so build the sentence to survive a blank, or reserve merge variables for properties every student genuinely has. See edit your email templates.
A worked example: a certification programme
Say you sell an accredited course to professionals who must report their training to a regulator, and employers often buy seats in blocks. Three properties carry almost the whole administrative burden of that programme, and none of them exists anywhere in Shopify.
- licence_number — captured at enrolment, needed on every completion record you submit.
- cohort — which intake they belong to, so a live session invite goes to the right forty people.
- employer — who is paying, so the sponsor gets one progress report instead of asking you for it.
The employer sends a spreadsheet of forty staff with their licence numbers. You import it once, tick two extra columns, and every one of those members carries their own facts from then on. At the end of the quarter, an export filtered to that cohort produces the regulator's file and the sponsor's report from the same download.
Pair that with the rest of the member surface and the picture is complete: progress and completion come from the course itself, a monthly progress email keeps the students moving between live sessions, and the properties tell you who each of them is to your business. If you are still designing the programme, the course launch checklist is the place to decide what you will need to record before the first cohort buys.
Frequently asked questions
A contact property is a named value you store against one member of your store, for a fact about that student that the Shopify customer record has nowhere to hold. It appears on the member's page in the admin and can be exported as its own column in the member CSV.
Anything your programme needs that is not already a Shopify field: cohort or intake, employer or sponsor, licence or registration number, referral source, mentor, seat number, renewal date or a purchase-order reference. Values are free text.
No. The same person can be a customer of several stores that use the app, and contact properties are stored per store. What you record about a student is visible on your member page only, and never on another merchant's.
Up to 100 distinct property names per store. Property names use lowercase letters, numbers and underscores and are between 3 and 64 characters. At the cap, existing properties stay editable and you retire a name before adding a new one.
Yes. When you import members, any column that is not part of the standard member import is offered as a contact property. Extra columns are unticked by default, and the importer shows you the property name it proposes for each column before anything is saved.
Yes. Each property your store uses is available as its own column in the member export, listed separately from the standard member columns in the column picker. Save a selection as a column set to reuse the same report each month.