People are keyed by your own identifier with the address as an attribute, so the same person can change address without becoming a new record. The export is a projection of your product database.
Getting the addresses out of Customer.io
The App API exports people and their attributes. Customer.io is API-first and CSV is the secondary path.
In the signup handler before the identify call fires. Event-triggered messaging begins immediately, so an unchecked address is mailed within minutes of being stored.
What Customer.io does with the file you bring back
The import rules decide what a re-import actually changes, which is worth knowing before you upload.
The short version
- People are keyed by your own ID, so the email is an attribute and can change without creating a duplicate.
- Suppressed addresses stay suppressed independently of attribute updates.
- Attributes hold arbitrary data, so a verification verdict and date belong there.
- Bulk updates go through the API rather than a file upload.
The mistake to avoid
Some addresses come back unresolved, and that is a fact about the receiving server rather than a gap in the check. We label those and never bill for them. What that means, and why roughly 28% of business addresses land there, is set out on our page about catch-all domains.
A 120,000-user backfill and the peak that gets billed
Suppose you're connecting Customer.io to a product with 120,000 user rows. About 31,000 of them never confirmed their address and have no activity after signup day. The quick plan is to sync everything and sort it out inside the workspace.
Customer.io's billing page explains why that's expensive. Overages are calculated from the highest number of profiles you had during the billing period, and a profile that existed at any point in the period counts for that month even if you delete it. Sync 120,000, delete 31,000 the next morning, and the month is still billed at the peak.
Check the 31,000 before the sync instead. Say 9,800 are invalid and 2,400 unknown. Leave the invalid ones out of the first identify batch, and your peak is 110,200. Our 50,000 pack covers the check for $89, and the 2,400 unknowns aren't charged.
Two different things are called suppression here
The first kind happens to an address. When a message hard bounces or draws a spam complaint, the email provider underneath Customer.io adds that address to its suppression list, and Customer.io won't send to it again. Their docs are careful to add that the person isn't deleted or changed. The profile stays in your workspace, stays in your segments and stays in your profile count.
A second kind is something you do to a person. Deleting a profile removes it, and your application can add it back with the same identifier on the next identify call. Suppressing a profile removes it and blocks that identifier from returning.
For dead addresses attached to abandoned accounts, the second one is usually what you want, since a plain delete gets undone by the next sync. Be sure before you use it on anyone who might come back as a paying customer.
Questions people ask
Where does verification belong with Customer.io?
In the signup flow, before the identify call writes the address. The people in Customer.io are a projection of your data, so upstream is the only durable place to fix it.
Can I store verification results as attributes?
Yes, and segments can filter on them, which lets you hold unresolved addresses out of a first touch without deleting the person.
Should I re-verify people already in the system?
Before any large broadcast to an older cohort, yes. Event-triggered messaging touches recent users constantly and older ones rarely, so that is where decay accumulates.