Contacts
A contact is one person in Mailtarget CDP. The Contact Book is the data store. Every contact has a primary email address, a status, optional labels, and any number of custom fields you define.
The fields
Every contact carries a fixed set of system fields plus any custom fields you add.
System fields
- Email. The primary key. One contact per email address per account.
- Name. Display name. Optional.
- Status. Active, Pending, Unsubscribed, or Hard Bounce. Set by Mailtarget based on subscription state and bounce events.
- Labels. Multi-value tag set. Used for filtering and segmentation.
- Source. Where the contact entered the Contact Book (form ID, manual add, import file, API call).
- Subscribed at. Timestamp of subscription.
- Funnel status. Aware, Engaged, Customer, Loyal Customer, or Promoter. See Journeys.
Custom fields
Custom fields hold per-contact data beyond the system set. A contact field is defined once and applies to every contact in the Contact Book.
Common patterns:
- Identity fields.
first_name,last_name,phone,country. - Behavioral fields.
last_purchase_date,lifetime_value,signup_source. - Operational fields.
external_user_id,subscription_tier,account_status.
Each custom field has a name (display) and a tag (template variable). The tag is fixed at creation; renaming the field does not rename the tag. Plan tag names before you create fields. The tag is what your templates reference.
Hello {{first_name}}, your subscription tier is {{subscription_tier}}.
Substitution data passed to the Transmission API overrides the contact field value for that one send. The contact field is the default; the request body is the override.
Status
Mailtarget tracks each contact's subscription status. The status determines whether the contact can receive sends.
| Status | Meaning | Can receive sends |
|---|---|---|
| Active | Confirmed subscriber. | Yes. |
| Pending | Subscribed but not yet confirmed (double opt-in flow). | No. |
| Unsubscribed | Clicked an unsubscribe link or marked spam. | No. |
| Hard Bounce | Receiving server permanently rejected the address. | No. |
Status transitions happen automatically based on engagement and bounce events. Do not flip status manually unless you have a reason and an audit trail.
The suppression list is a separate concept layered on top of contact status. A contact can be Active in the Contact Book but suppressed at the account level (compliance, complaint, or hard bounce). The send checks both. Read the bounce-classification operations doc for the policy.
Labels
Labels are tags. A contact can carry many labels at once. Use labels for:
- Source attribution (
source:landing-page-q2,source:webinar-jan). - Marketing intent (
vip,newsletter,power-user). - Operational state (
needs-followup,support-priority).
Labels feed segments. A segment defined as Label contains "vip" resolves to every active contact with the vip label.
Contact size and operations
The Contact Book displays sorted by email address. Two operations matter at scale:
- Import. CSV upload with field mapping. Used for migrations and one-shot loads.
- Export. Download all contacts as CSV. Used for audit and external sync.
For runtime operations (create contact on signup, update field on event, mark unsubscribed via webhook), use the API. The dashboard is for human operators; the API is for applications.
How contacts feed sending
Three patterns:
- Direct send to email. Submit to the Transmission API with
to: [{ email }]. The recipient does not need to exist in the Contact Book. Used for transactional sends keyed off your application data. - Send to segment. Define a segment in the dashboard. Reference it from a campaign or automation. Mailtarget resolves the segment at send time.
- Targeted send from the CDP funnel view. One-recipient send from the dashboard funnel surface. Used for operator-driven outreach to a single contact, not for application integration. See the targeted-send guide.
If your application needs to send transactional email keyed by user ID, the simplest path is direct send with metadata carrying your user ID. The Contact Book is not a required dependency.
Next
- Segmentation for filtering contacts into groups.
- Journeys for funnel-stage logic.
- The bounce-classification operations doc for status-transition policy.