Subscriber Preferences & Frequency — A Preference Center That Reduces Unsubscribes

For senders with sophisticated content programs (separate teams owning separate verticals) the single-list-with-topic-filter pattern can become unwieldy. Two scalable alternatives:

Per-topic lists (one list per topic):

Instead of one list with a topics multi-select, create separate AcelleMail lists per topic — product-updates, industry-news, events. Each list has its own subscribe/unsubscribe flow. Subscribers can be on all, some, or none.

Pros:

• Clean separation; each list's stats reflect its topic
• Each topic owner manages their list independently
• Subscriber unsubscribing from one topic stays on the others

Cons:

• Duplication of identity across lists (one person = N subscriber rows)
• Cross-list deduplication (segment "everyone on at least one list") needs manual setup
• Compliance auditing harder (per-topic unsubscribe records spread across N lists)

For ~10 topics or fewer, per-topic-lists works well. Above that, single-list-with-topic-filter scales better.

Preference center as a custom landing page:

The built-in Update form covers most cases. For brand-aligned UX (matches your website chrome, supports complex conditional fields), build a custom preference page on your own domain that calls AcelleMail's subscriber-update API on submit:

<form action="/preferences/update" method="POST">
  <input name="subscriber_token" value="{{ subscriber.token }}" type="hidden">
  <h2>Email preferences</h2>
  <label>How often?
    <select name="frequency">
      <option value="daily">Daily digest</option>
      <option value="weekly">Weekly digest</option>
      <option value="monthly">Monthly only</option>
    </select>
  </label>
  ...
  <button>Save</button>
</form>

Server-side handler:

$token = $request->input('subscriber_token');
$subscriber = decryptToken($token);

Http::withToken(env('ACELLE_TOKEN'))
   ->patch("https://acellemail.com/api/v1/subscribers/{$subscriber->uid}", [
       'fields' => $request->only(['frequency', 'categories', 'channel_email_marketing']),
   ]);

The subscriber token (signed JWT, expires in 7 days, references the AcelleMail subscriber UID) prevents URL-tampering — only the right person can update their preferences.

GDPR / CASL alignment — for EU + Canadian senders, the preference center is your compliance backbone:

• Per-purpose consent: GDPR Article 7 requires consent to be specific to each purpose. A single "marketing emails on/off" doesn't meet the bar — split into per-channel + per-content-type consent fields, each toggleable independently. AcelleMail's per-field consent log (in subscriber detail) records each consent grant + revocation with timestamp.

• Withdrawal as easy as grant: if subscribing was a single click, unsubscribing must be too. The preference center makes the granular withdrawal easy; the unsubscribe link is the blanket withdrawal — both must work.

• Right to access: GDPR Article 15 means subscribers can request all data you hold. Build a "Download my data" button on the preference center → calls AcelleMail's subscriber-export API → emails them a JSON with their fields + consent history. Most senders rarely get the request, but having the button defuses 90% of compliance complaints before they escalate.

Centralised preference center across multiple AcelleMail installs — for organizations with regional AcelleMail instances (EU + US + APAC for data-residency reasons), build a single preference center that fans out:

User updates preferences on prefs.example.com
   → Backend identifies which AcelleMail instances host this subscriber (could be multiple)
   → Parallel PATCH to each instance with the same field updates
   → Confirm all 200 OK before showing success to user

Worth doing only above a certain scale; below that, send users to the right regional center via a simple lookup.

Soft unsubscribe (suppression without deletion):

When a subscriber says "I'm done" you set status=unsubscribed rather than delete. The row persists; AcelleMail won't send to it; suppression list grows. This matters because:

• Re-uploading the same email (e.g. CRM sync) doesn't accidentally re-subscribe them
• Bounce reporting + complaint tracking remains intact
• Compliance audit can show "this address was on the suppression list since 2026-04-15"

In AcelleMail this is the default behaviour — clicking unsubscribe doesn't delete the row. Only Bulk delete in the admin UI hard-deletes.